--- Day changed Thu Oct 01 2015
00:02 < gmaxwell> I've brought up the mutate everythin approach, I think it's superior to just blocking completely.
00:02 < 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.
00:03 < gmaxwell> BlueMatt: it absolutely would break some wallets, but the same wallets are already super vulnerable.
00:03 < CodeShark_> this raises an interesting point...BIP62 could be deployed along with a new relay policy that mutates transactions...
00:03 < gmaxwell> Yes, its true. I'd only raised that before for lowS but its true generally.
00:04 < gmaxwell> if your transactions are BIP62 friendly you get no mutation, otherwise you're always mutated.
00:04 < BlueMatt> interesting deployment strategy :p
00:05 < 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. 
00:05 < gmaxwell> Even without the forced mutation, there is that RBF idea: if a lowS mutant comes in, replace.
00:06 < phantomcircuit> gmaxwell, which pretty much instantly devolves into mutate everything :)
00:06 < gmaxwell> means someone performing a mutation attack would have ~100% success on highS users and  ~0% success on others.
00:07 < gmaxwell> but absent an attack you're fine.
00:07 < gmaxwell> in any case, still leaves the general BIP62 problem that we're really not sure we got all the mutation vectors. :(
00:09 < gmaxwell> petertodd: fwiw this channel has existed since at least nov 2014.
00:12 < wumpus> it was created because people didn't want the github commit notifications on #bitcoin-dev
00:12 < wumpus> I think
00:16 < 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.
00:16 < gmaxwell> our commit volume is just not that high.
00:24 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:35 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
00:40 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has joined #bitcoin-core-dev
00:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
01:07 < btcdrak> merge and pull request notification are very useful and will increase collaboration.
01:09 < paveljanik> +1
01:10 < jgarzik> +1
01:11 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 256 seconds]
01:11 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
01:12 < wumpus> exactly, and we don't have that many commits that it gets in the way of discussion
01:21 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
01:22 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
01:22 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
01:25 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
01:34 -!- TZander [~quassel@kde/zander] has joined #bitcoin-core-dev
01:36 < CodeShark_> are we still going to do the weekly core dev meetings on thursdays?
01:36 < CodeShark_> at the same time?
01:36 < wumpus> yes
01:36 < jgarzik> yes
01:36 < gmaxwell> I was assuming. I hope it goes more orderly than last time.
01:37 < 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?
01:37 < jgarzik> Fedora has an IRC meeting robot for logging, tracking agenda items, and notably, moving along from one item to the next
01:38 < jgarzik> Many subgroups in the Fedora community have weekly IRC meetings and associated software gadgetry to help
01:38 < 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 :)
01:38 < wumpus> I have the following topics: CLTV(/CSV/...) deployment, mempool management. Feel free to suggest others
01:38 < gmaxwell> A lot of people (even IRC regulars) aren't really able to follow more than two concurrent discusisons.
01:38 < 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.
01:39 < jgarzik> https://wiki.debian.org/MeetBot
01:39 < gmaxwell> I did, at least but maybe too promptly and have started swapping them out again. :(
01:39 < btcdrak> jgarzik: aj is adding that to the logging bot
01:40 < jgarzik> channel denizens tell MeetBot when topic A is finished, and it moves on to topic B
01:40 < jgarzik> produces nicely separated-out summaries by topic if necessary
01:40 < btcdrak> jgarzik: like this http://meetbot.debian.net/debconf-team/2015/debconf-team.2015-01-19-19.59.html
01:40 < jgarzik> yep
01:41 -!- Naphex [~naphex@unaffiliated/naphex] has joined #bitcoin-core-dev
01:41 < btcdrak> well with any luck aj will have it setup for today's meeting, but otherwise, it will be there for sure next week
01:45 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
01:48 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 240 seconds]
01:49 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
01:52 < 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 )
01:53 < Naphex> wumpus: that hearnban was best thing all month / grats
01:55 < 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.
01:56 < wumpus> Naphex: yeah, it was about time
01:56 < 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.
01:57 -!- BashCo [BashCo@gateway/vpn/mullvad/x-azeqsolsubtdvrmk] has joined #bitcoin-core-dev
01:57 < gmaxwell> For many years I used BitchX in a single window mode, while being in a dozen high traffic channels. :P
01:57 < wumpus> jgarzik: I was not posting it to argue with btcdrak :) just for information, re: the 'homework'
01:57 < wumpus> gmaxwell: I'm kind of slow so I have trouble following such things in real time :)
01:58 < 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.
01:59 < wumpus> I can read the English fast enough, these days, but following the chaos of different concerns at the same time can be problematic
02:20 < GitHub193> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1119cc3f5918...12a7712abd49
02:20 < GitHub193> bitcoin/master 835c122 Daniel Kraft: Clean up change computation in CreateTransaction....
02:20 < GitHub193> bitcoin/master 12a7712 Wladimir J. van der Laan: Merge pull request #5924...
02:20 < GitHub126> [bitcoin] laanwj closed pull request #5924: Clean up change computation in CreateTransaction. (master...change-cleanup) https://github.com/bitcoin/bitcoin/pull/5924
03:00 < GitHub55> [bitcoin] jgarzik pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/12a7712abd49...cf9bb11f97db
03:00 < GitHub55> bitcoin/master 9524c4d Tom Harding: In (strCommand == "tx"), return if AlreadyHave()...
03:00 < GitHub55> bitcoin/master cf9bb11 Jeff Garzik: Merge pull request #6588
03:01 < GitHub1> [bitcoin] jgarzik closed pull request #6588: In (strCommand == "tx"), return if AlreadyHave() (master...already_have) https://github.com/bitcoin/bitcoin/pull/6588
03:03 < GitHub178> [bitcoin] jgarzik pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf9bb11f97db...8a86d53bd570
03:03 < GitHub178> bitcoin/master 9639ead Wladimir J. van der Laan: doc: Add build guide for OpenBSD 5.7...
03:03 < GitHub178> bitcoin/master 8a86d53 Jeff Garzik: Merge pull request #6731
03:03 < 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
03:18 < 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
03:19 < btcdrak> nice work aj
03:20 < aj> btcdrak: you suck at pretending i didn't say anything btw :-P
03:20 < btcdrak> haha :)
03:21 < jgarzik> Trolling for reviews, add bip32 pub key serialization #6215 https://github.com/bitcoin/bitcoin/pull/6215
03:23 < jgarzik> Trolling for reviews, Bugfix: Fix testnet-in-a-box use case #5987 https://github.com/bitcoin/bitcoin/pull/5987
03:23 < btcdrak> Trolling for reviews, Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312
03:23 < btcdrak> Trolling for reviews, Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564
03:25 < sipa> aj: who can give the bot commands?
03:26 < sipa> ah, the one who starts the meeting?
03:26 < jgarzik> btcdrak, (cc maaku): is there anywhere where use cases are discussed?  BIP 112 just has one example
03:26 < aj> sipa: i think someone says #startmeeting and becomes the chair as a result
03:26 < jgarzik> some meeting bots allow channel participants to vote on "moving along"
03:26 < jgarzik> which can be helpful with contentious discussion that do not have a single chair
03:27 < btcdrak> jgarzik: BIP112 cites references where there are a ton of other uses
03:27 < btcdrak> jgarzik: for example: http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
03:27 < jgarzik> btcdrak, I must be blind :)   I see one other reference related to use case, HTLC
03:28 < jgarzik> "ton of" == 2 :)
03:28 < btcdrak> :) I'm guilty of hyperbole
03:28 < CodeShark_> if the units are 1000 lbs, then yes, "ton of" == 2
03:30 < 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.
03:32 < CodeShark_> its main purpose there is in providing a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction
03:33 < CodeShark_> absolute time lock means we need to close the channel and reopen it when we're getting close to the timeout
03:33 < CodeShark_> relative time lock means the clock starts ticking the moment the transaction gets in the block
03:35 < 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
03:38 < CodeShark_> even if this were the only use case, I'd still say it's worth doing :)
03:40 -!- Aquentin [~Aquentin@unaffiliated/aquentin] has joined #bitcoin-core-dev
03:40 < CodeShark_> the only nit I can possibly find is around naming
03:40 < CodeShark_> but as I've said before...meh
03:42 < jgarzik> Sorry, got my BIPs mixed up.  It's BIP 68 that I need to understand deeply & thoroughly.
03:42 < jgarzik> redefinitions always make me nervous :)
03:45 < btcdrak> jgarzik: Should be clear in the BIP68 text. 
03:46 < jgarzik> I wish BIPs were assigned 8-letter alphabetic codes; easier to disambiguate ;p
03:49 < wumpus> I like the short numbers
03:51 < wumpus> although I agre they're easy to confuse sometimes, but at least they stick in memory at some point
03:51 < 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
03:52 < 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
03:53 < wumpus> we had that at some point, but it probably broke when moving to a git repo instead of the wiki
03:53 < jgarzik> yeah, someone snag bitrfc.co and connect it to a bot
03:53 < TZander> I saw a wiki that is backed by a git repo; best of both worlds.
03:54 < Aquentin> I'm a bit scared, looks like a purge is going on...???
03:55 < sipa> ?
03:55 < Aquentin> why was this channel created?
03:56 < CodeShark_> to track merges and pull requests ;)
03:56 < TZander> Aquentin: Channel #bitcoin-core-dev created on Mon Nov 17  2014
03:56 < Aquentin> it didnt get a log bot until yesterday
03:56 < CodeShark_> yes, now it also contains dialog
03:57 < Aquentin> does jgarzick and gavinandresen have mod here?
03:57 < wumpus> to avoid political meta discussion, and focus on develpoment of the Bitcoin Core project in github.com/bitcoin/bitcoin
03:57 < wumpus> so strictly you're off topic
03:57 < 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
03:57 < wumpus> last warning
03:58 < TZander> wumpus: thats a bit harsh...
03:59 < wumpus> I have to be, to avoid this becoming #bitcoin-dev again
03:59 < TZander> I think thats what they are talking about when people say that resolving issues is best. Otherwise they tend to follow you around.
04:00 < TZander> anyway #bitcoin-dev is kinda empty right now
04:00 < wumpus> the list of issues to be resolved here is at: https://github.com/bitcoin/bitcoin/issues  , there are 367 open, good luck
04:01 < wumpus> after they're all closed, we could talk about something else :)
04:02 < jonasschnelli> jgarzik: cfields: does this makes sense: https://github.com/jonasschnelli/bitcoin/commit/37b779d031059982111f352ffe0c18b336113bba
04:03 < jonasschnelli> that change did work on my local machines (osx/debian)
04:03 < jonasschnelli> maybe L34 change is wrong... will double-check.
04:05 < TZander> wumpus: I'm not the one that has to resolve your issues ;)
04:06 < 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
04:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
04:10 < 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
04:11 < Aquentin> this isn't your project to dictate by ostracising
04:11 < CodeShark_> go away
04:12 < stonecoldpat> ugh, mod doesn't matter. People are here just to do work, please respect the channel. 
04:12 < Aquentin> course it matters... banning developers from contributing does matter
04:12 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
04:13 -!- mode/#bitcoin-core-dev [+b *!*@unaffiliated/aquentin] by wumpus
04:13 -!- Aquentin was kicked from #bitcoin-core-dev by wumpus [nothere]
04:13  * jonasschnelli hopes this channel keeps troll free and is used only for tech. topics
04:13 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
04:28 < 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.
04:34 < 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.  
04:35 < CodeShark_> we don't want that attitude in here, regardless of the specific question
04:36 < CodeShark_> anyone can create their own channel and discuss whatever topics they like
04:36 < 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.
04:37  * wumpus does need to actually add more moderators at some point here, but it has nothing to do with who is developer or not
04:47 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
04:48 -!- wumpus changed the topic of #bitcoin-core-dev 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/
04:48  * wumpus stole #tor-dev's topic line
04:48 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ, ChanServ
04:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
05:11 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 265 seconds]
05:12 < GitHub144> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8a86d53bd570...4899a04c24b9
05:12 < GitHub144> bitcoin/master e761d7a Luke Dashjr: Bugfix: Allow mining on top of old tip blocks for testnet (fixes testnet-in-a-box use case)
05:12 < GitHub144> bitcoin/master 4899a04 Wladimir J. van der Laan: Merge pull request #5987...
05:12 < 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
06:27 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/6637 <--- seeks for a final review
06:50 -!- Cocodude [~marc@109.169.23.186] has joined #bitcoin-core-dev
06:52 < 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
06:57 < Cocodude> Is anyone seeing a lot of transaction malleability on the network again?
06:58 < wumpus> michagogo: because bitchx was l33t and had lots of colors :)
06:58 < wumpus> Cocodude: haven't noticed yet
06:59 < 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"!
07:00 < 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.
07:02 < jonasschnelli> btcdrak: better: https://github.com/bitcoin/bitcoin/pull/6637?
07:03 < Cocodude> (we're only using Insight as a URL to give to users to show their transaction details)
07:03 < btcdrak> jonasschnelli: yes!
07:03 -!- assadasafrt [2e25895c@gateway/web/freenode/ip.46.37.137.92] has joined #bitcoin-core-dev
07:04 < wumpus> well it's possible that someone is sneakily mutilating transactions on the network before relaying
07:04 < btcdrak> Cocodude: Use another block explorer like blocktrail.com
07:04 < jonasschnelli> btcdrak: Okay. Thanks for pointing this out. 
07:04 < Cocodude> btcdrak: Yes, I think I will
07:05 < wumpus> Cocodude: do you have a copy of the tx hex of the original and conflicting transaction?
07:05 < 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.
07:05 < Cocodude> wumpus: One example is https://www.blocktrail.com/BTC/tx/8c6995a207c79de1c356bc07fa23f3e2e76c73d9cb18a8bf84baad125104bad5
07:06 < Cocodude> But it's happened with a few txns over the last hour or so
07:06 -!- assadasafrt [2e25895c@gateway/web/freenode/ip.46.37.137.92] has left #bitcoin-core-dev []
07:15 < wumpus> blocktrail doesn't make it easy to get at the raw tx data (can't find it)
07:15 < wumpus> someone on #bitcoin also reporting malleated transactions
07:22 < GitHub147> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4899a04c24b9...17d0e638b66b
07:22 < GitHub147> bitcoin/master 110a1fd Jonas Schnelli: enable zmq-test in rpc-tests.sh
07:22 < GitHub147> bitcoin/master a9c27cd Jonas Schnelli: [travis] add zmq python module
07:22 < GitHub147> bitcoin/master 745f909 Cory Fields: travis: install a recent libzmq and pyzmq for tests
07:22 < 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
07:28 < helo> nice bot...
07:30 < Cocodude> A follower on twitter interestingly stated that BIP66 should have sorted out the fake double spends. Is BIP66 live?
07:34 -!- rubensayshi [~ruben@91.206.81.13] has quit [Read error: Connection reset by peer]
07:34 < TZander> Cocodude: not related, and yes. For some time now.
07:34 < Cocodude> Ah, OK, ta
07:35 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
07:35 < wumpus> Cocodude: that's BIP62, not BIP66. BIP66 forces strict DER encoding for signatures, it does not address other malleability issues
07:36 < Cocodude> Got it. I'll keep an eye on BIP62's progress
07:36 < GitHub50> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/17d0e638b66b...f297042cae57
07:36 < GitHub50> bitcoin/master 0917306 Jonas Schnelli: remove univalue, prepare for subtree
07:36 < GitHub50> bitcoin/master 2f9f082 Jonas Schnelli: Squashed 'src/univalue/' content from commit 87d9045...
07:36 < GitHub50> bitcoin/master 6e16a41 Jonas Schnelli: Merge commit '2f9f082b5ef3c495c70598ef23383effef675f9a' as 'src/univalue'
07:36 < GitHub25> [bitcoin] laanwj closed pull request #6637: Add UniValue as subtree (master...2015/09/univalue_subtree) https://github.com/bitcoin/bitcoin/pull/6637
07:38 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/6215 <-- trivial review, code is only used in unit tests right now
07:40  * jonasschnelli has sunken so low that he's cheerleading his pull requests, .. 
07:42 < wumpus> well it's good to get the number of open pulls down a bit
07:43 < paveljanik> UniValue compiles cleanly here - OS X, clean build
07:43 < paveljanik> congrats!
07:45 < jonasschnelli> paveljanik: thanks for letting us know!
07:46 < 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
07:47 < wumpus> that pull moved to the univalue repository?
07:49 < jonasschnelli> wumpus: yeah. Need to do that upstream now... that was one of the goals, ... to improve UniValue without disturbing bitcoin-core.
07:50 < jonasschnelli> Only do a UniValue-Upgrade PR if there are reasonable changes that are worth merging.
07:50 < jonasschnelli> UniValue is also inconsistent with code style... get_str() and IsStr(), etc. Have plans to make it clean.
07:51 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:51 < wumpus> yes, it's mixing bitoin-core style UpperCamelCase methods  with c_style_names, better to decide on one :)
07:52 < jonasschnelli> Right. I think it was mainly done this way because it reduced the diff when switch from json_spirit to univalue.
07:52 < wumpus> smaller diff, yes likely
07:53 < sipa> wumpus: is the meeting in this channel?
07:54 < wumpus> sipa: it's still on the schedule as #bitcoin-dev. Could announce a new channel, don't know what makes sense.
07:54 < sipa> either is fine to me, just want to know
07:55 < jonasschnelli> Maybe its better communication to do it on #bitcoin-dev unless there are clear infos about where the next irc meeting will be
07:55 < sipa> ok, #bitcoin-dev
07:55 < 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
07:55 < wumpus> right
07:56 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
08:01 -!- ParadoxSpiral [~ParadoxSp@p508B9B56.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:02 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
08:09 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Quit: testing rejoin]
08:10 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:10 < jgarzik> jonasschnelli, wumpus:  json_spirit used find_value get_int etc.  It would be better to move to consistency with CamelCaps.
08:11 < jonasschnelli> jgarzik: i'm currently doing this right tow :) .. will open a PR soon
08:11 < jonasschnelli> things like s/get_str()/getString() ... etc.
08:12 < jgarzik> +1
08:13 < jonasschnelli> the only function i'll keep is push_back (instead of pushBack) to keep it more std::vector compatible.
08:13 < wumpus> lowerCamelCast or UpperCamelCase? :p
08:14 < jgarzik> jonasschnelli, nod - that was the idea - match STL naming where possible, since it is a container.
08:15 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:15 < jonasschnelli> jgarzik: okay.. i'll keep that and use lowerCamelCast for non STL calls
08:15 < jgarzik> jonasschnelli, the typical C++ recommended naming is BlahBlah for classes and blahBlah for methods
08:15 < jgarzik> AFAIK
08:15 < wumpus> yes, that's also what I have mostly seen
08:16 < wumpus> at least Qt does that
08:16 < jgarzik> ditto for class members
08:16 < jonasschnelli> lowerCamelCast for functions is a quasi standard for oo languages.
08:16 < wumpus> I've seen C conventions used for methods/properties, but never UpperCamelCase before Satoshi =)
08:16 < jonasschnelli> s/functions/methods 
08:17 < sipa> wumpus: Google has BlahBlah both for functions and methods
08:17 < jgarzik> I've seen C++ using BlahBlah for functions many times
08:17 < jgarzik> (as distinguished from methods)
08:17 < wumpus> sipa: ooh
08:20 -!- lightningbot_ [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:25 -!- ligh2ningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:26 -!- Cocodude [~marc@109.169.23.186] has left #bitcoin-core-dev []
08:30 -!- lig0tningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:33 -!- Eliel [~jojkaart@jkaartinen.iki.fi] has joined #bitcoin-core-dev
08:37 -!- ligh2ningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
08:37 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
08:38 -!- lig0tningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
08:38 -!- lightningbot_ [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
08:38 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
08:45 < jgarzik> jonasschnelli, do you think push_backV() should remain push_backV() to be consistent with STL?
08:46 < jgarzik> jonasschnelli, I have no opinion on pushV() vs. push_backV()
08:48 < jonasschnelli> jgarzik: push_backV is a univalue only interface (as far as i know). So it should follow the lowerCamelCase rules.
08:49 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
08:49 < jgarzik> jonasschnelli, true, but it seems very much like push_back() :)    Just a data point, not an objection...
08:50 < jgarzik> jonasschnelli, it's really vector.insert(vector.end(), list...)
08:54 < jonasschnelli> jgarzik: yeah. Also no strong opinion about that. I just don't like to many mixes like get_bool and isString(), etc.
08:54 < jcorgan> regarding #6679, should the check for zmq library be moved up to L665, where the other libraries are checked?
08:55 < jcorgan> to that section, that is 
08:55 < jgarzik> jcorgan, lean "yes"
08:56 < wumpus> that's something you should ask cfields I think :)
08:57 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 250 seconds]
08:57 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
08:57 < jcorgan> i'll try it out, unless he comments here in time
09:04 -!- BashCo_ [~BashCo@wall.nureg.de] has joined #bitcoin-core-dev
09:06 < jcorgan> btw, i think src/univalue/build-aux and src/univalue/pc need .gitignores for build artifacts
09:06 -!- BashCo_ [~BashCo@wall.nureg.de] has quit [Read error: Connection reset by peer]
09:07 -!- BashCo [BashCo@gateway/vpn/mullvad/x-azeqsolsubtdvrmk] has quit [Ping timeout: 255 seconds]
09:12 < GitHub186> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f297042cae57...bb882d04e862
09:12 < GitHub186> bitcoin/master 5978388 Wladimir J. van der Laan: build: remove libressl check...
09:12 < GitHub186> bitcoin/master a3874c7 Wladimir J. van der Laan: doc: no longer require use of openssl in OpenBSD build guide
09:13 < GitHub186> bitcoin/master bb882d0 Wladimir J. van der Laan: Merge pull request #6732...
09:13 < GitHub119> [bitcoin] laanwj closed pull request #6732: build: remove libressl check (proposal) (master...2015_09_remove_libressl_check) https://github.com/bitcoin/bitcoin/pull/6732
09:13 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 250 seconds]
09:13 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
09:14 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
09:14 < GitHub185> [bitcoin] laanwj closed pull request #5079: Accept any sequence of PUSHDATAs in OP_RETURN outputs (master...op-return-accept-multiple-pushdatas) https://github.com/bitcoin/bitcoin/pull/5079
09:15 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev
09:18 < btcdrak> wumpus: meetbot is not setup for #bitcoin-dev, so better here.
09:19 < wumpus> I understand, but well it's too late to announce a new channel for the meeting now, IMO. So more luck with that next week then.
09:20 < jgarzik> Is it a Bitcoin Core meeting or bitcoin protocol meeting?  If the former, have the meeting in here, and keep an eye on #bitcoin-dev for any stragglers
09:20 < btcdrak> change the MOTD of #-dev to say it's here
09:21 < sipa> i think we want to discuss things like the ongoing BIPs
09:21 < jgarzik> MOTD + ML note + watch for stragglers and tell them
09:21 < wumpus> well I guess both types of issues get discussed, e.g. rollout of softforks
09:21 < wumpus> but also bitcoin core specific stuff like the mempool management
09:21 -!- n0n0_ [~n0n0@x5f768399.dyn.telefonica.de] has joined #bitcoin-core-dev
09:21 < jgarzik> ok, #bitcoin-dev as planned
09:21 < jgarzik> and suffer lack of meetbot :)
09:22 < sipa> perhaps over time it makes sense to split them up... core meetings are probably useful more frequently than protocol meetings
09:22 < jgarzik> ~strikethrough~  was just typing same thing as sipa :)
09:22 < jgarzik> they will most likely diverge eventually into two meetings anyway
09:23 < wumpus> yes that makes sense
09:24 < Naphex> why have this backwards compat?
09:24 < Naphex> anyway
09:24 < Naphex> then just move back to #bitcoin-dev and get jgarzik too stop removing the bans
09:24 < Naphex> done
09:24 < wumpus> Naphex, stop it
09:25 < GitHub35> [bitcoin] jmcorgan opened 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
09:25 < Naphex> consider it stopped / but have been annoyed by all this stuff for months now
09:29 < wumpus> we all have, but let's not pollute this channel with it :)
09:29 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds]
09:29 < Naphex> i agree / rgr. well back to work
09:30 -!- zooko [~user@172.56.9.30] has joined #bitcoin-core-dev
09:38 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev
09:43 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
09:43 < GitHub70> [bitcoin] laanwj opened pull request #6744: build: disable -Wself-assign (master...2015_10_clang_self_assignment_warning) https://github.com/bitcoin/bitcoin/pull/6744
09:57 -!- zooko [~user@172.56.9.30] has quit [Read error: Connection reset by peer]
09:58 -!- zooko [~user@172.56.9.30] has joined #bitcoin-core-dev
10:00 < maaku> jgarzik: sidechain peg is another application. it was hard finding an example that stood alone however, hence the simple payment channel
10:12 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:15 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:24 < gmaxwell> maaku: For CSV?  there are a bunch; many look a lot like payment channels, but they're distinct.   For example, 2 of 2 anti doublespend
10:25 < gmaxwell> The parties today doing 2 of 2 anti-doublespend use nlocktime refunds, they'd later move to CLTV refunds, but the absolute time refunds are kind of lame compared to dynamic ones.
10:27 -!- zooko [~user@172.56.9.30] has quit [Ping timeout: 240 seconds]
10:29 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]
10:32 < maaku> gmaxwell: thank you I'll see if I can work those out and add to the bip 112 document
10:48 -!- guruvan [~guruvan@unaffiliated/guruvan] has joined #bitcoin-core-dev
11:04 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 256 seconds]
11:06 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
11:32 -!- ParadoxSpiral_ [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:35 -!- ParadoxSpiral [~ParadoxSp@p508B9B56.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
11:41 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:45 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving]
11:55 -!- BashCo [BashCo@gateway/vpn/mullvad/x-okcwposlklwyvfoo] has joined #bitcoin-core-dev
11:56 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
12:01 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev
12:03 -!- CodeShark is now known as CodeShark__
12:03 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit []
12:03 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
12:05 < warren> meeting here?
12:06 < wumpus> in #bitcoin-dev still
12:06 < sipa> no, in #bitcoin-dev
12:07 -!- belcher_ [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:09 < paveljanik> can we have a bot here "expanding" PR numbers? E.g. after entering #6550, it could print: Obfuscate chainstate (https://github.com/bitcoin/bitcoin/pull/6650).
12:10 < sipa> would be nice
12:10 < jgarzik> +1
12:10  * jgarzik thought gribble could do that...
12:11 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:11 < gmaxwell> I'd prefer it be another bot so I can ignore it, I generally don't like that functionality, esp when the number gets used 10 times in an hour and its chatting up my backlog.
12:13 < wumpus> it could remember what numbers it translated before I guess and refuse to expand them again within a certain time
12:14 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-lelvtramvtglswdq] has joined #bitcoin-core-dev
12:14 -!- BashCo [BashCo@gateway/vpn/mullvad/x-okcwposlklwyvfoo] has quit [Read error: Connection reset by peer]
12:16 < jgarzik> Have humans be the limiters via explicit request.  Use /EPR\s*#\d+/ to trigger a one-line expansion
12:16 -!- Cocodude [~marc@109.169.23.186] has joined #bitcoin-core-dev
12:17 < jgarzik> Then you must proactively select to use "I  am hacking on EPR# 1234" in a normal sentence
12:17 < Cocodude> Sorry, quick lazy question - what's the bitcoind source file that defines the prefix for the pubkey and script address hashes?
12:17 < Cocodude> I thought it was base54.h but it doesn't seem to be, at least in the later bitcoinds
12:17 < sipa> chainparams
12:18 < sipa> or basechainparams
12:18 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:18 < Cocodude> Sweet, thanks for that
12:18 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:18 -!- lightningbot_ [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:18 -!- lightn3ngbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:18 -!- l4ghtningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:18 -!- light1ingbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:19 -!- lightningb6t [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:19 -!- lightnin7bot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:19 -!- lig5tningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:19 -!- ligh5ningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
12:25 < gmaxwell> !ops
12:29 < GitHub54> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/bb882d04e862...cd78c2a421ae
12:29 < GitHub54> bitcoin/master 6a07eb6 Peter Todd: Make TX_SCRIPTHASH clear vSolutionsRet first...
12:29 < GitHub54> bitcoin/master 5d8709c Peter Todd: Add IsPushOnly(const_iterator pc)...
12:29 < GitHub54> bitcoin/master da894ab Peter Todd: Accept any sequence of PUSHDATAs in OP_RETURN outputs...
12:29 < 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
12:31 < warren> Why are there a ton of ligtningbots?
12:32 < jonasschnelli> good question,.. :)
12:33 < 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?
12:33 < sipa> there is an array with all prefixes, initialized for each chain separately in chainparams
12:33 < btcdrak> warren: I've PMd aj who owns the loggers.
12:35 < Cocodude> base58Prefixes I assume?
12:36 < sipa> yes
12:36 < 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.
12:36 < Cocodude> Sorry :p
12:39 < warren> not sure if asking about the status of RCLTV is on-topic
12:59 -!- pavel__ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
12:59 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: No route to host]
12:59 -!- pavel__ [~paveljani@79-98-72-216.sys-data.com] has quit [Remote host closed the connection]
13:00 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
13:00 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
13:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
13:02 -!- light1ingbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
13:03 -!- li3htningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
13:23 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:34 -!- BashCo [BashCo@gateway/vpn/mullvad/x-pyzysvoxxdfcxebm] has joined #bitcoin-core-dev
13:35 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-lelvtramvtglswdq] has quit [Ping timeout: 272 seconds]
13:46 < gmaxwell> Can we talk some about the specific activities needed to get CSV ready for deployment?
13:46 < btcdrak> shoot
13:47 < gmaxwell> maaku has been busting his rear trying to get it in, and he'll do whatever it takes but I think right now its not precisely clear what the gaps (code or process wise) are that need to be filled.
13:47 < GitHub65> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cd78c2a421ae...19c71864258f
13:47 < GitHub65> bitcoin/master 96106f0 paveljanik: [Trivial] start the help texts with lowercase
13:47 < GitHub65> bitcoin/master 19c7186 Wladimir J. van der Laan: Merge pull request #6739...
13:47 < GitHub173> [bitcoin] laanwj closed pull request #6739: Trivial: start the help texts with lowercase (master...patch-9) https://github.com/bitcoin/bitcoin/pull/6739
13:48 < btcdrak> gmaxwell: I think it just needs code reviews
13:48 < btcdrak> this is the list
13:48 < btcdrak> BIP68 Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312
13:48 < btcdrak> BIP112 Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564
13:48 < btcdrak> BIP113 Mempool-only Median time-past as endpoint for lock-time calculations https://github.com/bitcoin/bitcoin/pull/6566
13:48 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:48 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:48 -!- lightningbot` [~supybot@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:48 -!- lightn3ngbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:48 -!- lightningbot_ [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:48 < btcdrak> I've asked a bunch of people privately to take a look, I'm not sure what else to do.
13:49 -!- l4ghtningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:49 -!- li2htningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:49 -!- li3htningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:49 -!- lightningb6t [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:49 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 256 seconds]
13:49 < btcdrak> gmaxwell: they are all ready for merging from maaku's perspective. They have all been rebased.
13:49 -!- lig5tningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:49 -!- lightnin7bot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:50 -!- lightningbot_ [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:50 < wumpus> BIP112 is 'CSV' right? are the others depndent on that?
13:50 -!- lightningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:50 -!- ligh5ningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 246 seconds]
13:50 -!- lightningbot` [~supybot@cerulean.erisian.com.au] has quit [Read error: Connection reset by peer]
13:50 -!- lightningb7t [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:50 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
13:51 -!- aj [~aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:51 -!- lightningbot` [~supybot@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:51 < btcdrak> wumpus: BIP68 redefines nSequence, BIP112 creates an opcode for it.
13:51 <@wumpus> aj: can you fix your bot please? it's entering and exiting all the time
13:51 <@wumpus> btcdrak: okay, thanks
13:51 < maaku> BIP68 / #6312 and BIP112 / #6564 are dependency-free
13:51 -!- lightning5ot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 < maaku> BIP113 / #6566 builds off #6312
13:52 -!- lightningbo5 [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- lig0tningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- lightningbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:52 -!- li5htningbot [~supybot@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- lightningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- lightn6ngbot [~supybot@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- light2ingbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- mode/#bitcoin-core-dev [+b *!~supybot@cerulean.erisian.com.au] by wumpus
13: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)
13:52 -!- lightni3gbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:52 -!- ligh9ningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:53 -!- lightni5gbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:53 -!- mode/#bitcoin-core-dev [+b *!lightningb@cerulean.erisian.com.au] by wumpus
13:53 -!- mode/#bitcoin-core-dev [+b *!supybot@2400:8900::f03c:91ff:fedf:3a06] by wumpus
13:54 <@wumpus> aj: let me know when you fixed the issues, then I'll unban them again
13:54 < btcdrak> maaku: so we could actually merge BIP112 now
13:54 -!- li2htningbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:54 -!- lightningbot` [~supybot@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:55 < gmaxwell> maaku: has there been any objections (at all) to BIP113? 
13:55 -!- lightningbot_ [lightningb@cerulean.erisian.com.au] has quit [Ping timeout: 264 seconds]
13:55 -!- aj [~aj@cerulean.erisian.com.au] has quit [Ping timeout: 260 seconds]
13:56 -!- lig0tningbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:56 -!- lightn6ngbot [~supybot@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:56 -!- li5htningbot [~supybot@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:56 -!- lightni3gbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:56 -!- lightningbo5 [lightningb@cerulean.erisian.com.au] has quit [Ping timeout: 264 seconds]
13:56 -!- lightning5ot [lightningb@cerulean.erisian.com.au] has quit [Ping timeout: 264 seconds]
13:56 < CodeShark> wumpus, supybot didn't listen
13:56 -!- lightni5gbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:57 -!- lightningb7t [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
13:57 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
13:58 -!- ligh9ningbot [lightningb@cerulean.erisian.com.au] has quit [Read error: Connection reset by peer]
13:58 <@wumpus> they're all leaving
13:58 -!- lightningbot [lightningb@cerulean.erisian.com.au] has quit [Ping timeout: 265 seconds]
13:59 -!- light2ingbot [lightningb@cerulean.erisian.com.au] has quit [Read error: Connection reset by peer]
14: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.
14:01 < btcdrak> gmaxwell: and in that case, it means BIP68 is required too.
14:01 < sipa> bip68 doesn't change locktime semantics
14:01 < btcdrak> since BIP113 builds on 68
14:02 < gmaxwell> btcdrak: artifact of software.
14:05 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit []
14:05 -!- CodeShark__ is now known as CodeShark
14:05 < gmaxwell> Okay, so it sounds like main limitations are just on software review.
14:06 < gmaxwell> I know that PT had some specific documentation asks related to 68/112, basically he wanted more usecase examples.
14:06 < GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/19c71864258f...5ab5dca6f1bb
14:06 < GitHub196> bitcoin/master 5467820 ptschip: Migrated rpc-tests.sh to all python rpc-tests.py...
14:06 < GitHub196> bitcoin/master 5ab5dca Wladimir J. van der Laan: Merge pull request #6616...
14:06 < 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
14:07 < gmaxwell> Which I think is reasonable. I suggested another candidate example space to maaku earlier today.
14:07 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
14:08 < gmaxwell> though generally I think most CLTV cases can be restated 'But with relative locktime!' and end up with a more robust protocol.
14:08 < btcdrak> gmaxwell: indeed
14:13  * btcdrak is impressed. The number of open PRs has reduced by 11+ in the last 24 hours...
14:15 < Anduck> closed or merged?
14:16 <@wumpus> either
14:19 -!- Jaamg [jhpiloma@gateway/shell/tkk.fi/x-sbbebcqcbuvuwpgc] has joined #bitcoin-core-dev
14:22 < btcdrak> do we want a bot to expand pull request numbers to URLs in this channel? 
14:23 < kanzure> i am fine if the bot is only doing that
14:23 < kanzure> (e.g. no (automatic) titlebot spam)
14:23 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
14:24 <@wumpus> I don't think it should expand all pull request numbers, we use them too much here
14:25 <@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
14:28 -!- palexander [~Patrick@67.41.40.110] has joined #bitcoin-core-dev
14:30 -!- palexander [~Patrick@67.41.40.110] has left #bitcoin-core-dev ["Leaving"]
14:33 < gmaxwell> yea, thats good.
14:38 -!- n0n0_ [~n0n0@x5f768399.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
14:43 <@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.
14:43 < gmaxwell> man that would be nice.
14:44 -!- BashCo [BashCo@gateway/vpn/mullvad/x-pyzysvoxxdfcxebm] has quit [Ping timeout: 272 seconds]
14:44 < devrandom> wumpus: perhaps https://github.com/defunkt/github-gem can help, not sure how much PR support it has
14:47 -!- ParadoxSpiral_ [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
14:47 <@wumpus> devrandom: thanks, seems it has issues support, but don't see anything about PRs either (but maybe it includes that)
14:49 < kanzure> wumpus: there's a github cli client that the github people maintain
14:50 < kanzure> wumpus: https://github.com/github/hub
14:56 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
14:59 -!- Crypton [~Crypton@unaffiliated/apocalyptic/bot/crypton] has joined #bitcoin-core-dev
15:05 < maaku> gmaxwell: if anyone has any objections re: 113, they have yet to voice them
15:08 < GitHub142> [bitcoin] laanwj closed pull request #5422: Update block-tester (master...mempoolfix4) https://github.com/bitcoin/bitcoin/pull/5422
15:09 < 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
15:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
15:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
15:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
16:12 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
16:12 < nanotube> !bpr 5422
16:12 < gribble> Update block-tester by TheBlueMatt · Pull Request #5422 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/5422
16:13 < nanotube> ^ have fun. as requested.
16:14 < sipa> !bpr 4096
16:14 < gribble> variable was used before it was initialized by tuttleorbuttle · Pull Request #4096 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/4096
16:15 < sipa> does it work inside (,,bpr 4096)
16:15 < sipa> or something like that
16:17 < nanotube> commas first
16:17 < nanotube> like ,,(bpr 4096)
16:17 < gribble> variable was used before it was initialized by tuttleorbuttle · Pull Request #4096 · bitcoin/bitcoin · GitHub | https://github.com/bitcoin/bitcoin/pull/4096
16:25 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has joined #bitcoin-core-dev
16:40 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:44 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:06 < jcorgan> ok, #6743 passes travis finally
17:21 < phantomcircuit> I dont think we need the "Address refresh broadcast" in main.cpp now that addrKnown is a CRollingBloomFilter
17:30 < phantomcircuit> gavinandresen, sanity check on above statement?
17:37 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:38 < phantomcircuit> ie the filter will "forget" an addr after 5000 inserts anyways so there's no reason to clear it
17:43 < GitHub53> [bitcoin] pstratem opened pull request #6745: Net: Remove "Address refresh broadcast" logic. (master...addr_known_reset) https://github.com/bitcoin/bitcoin/pull/6745
17:52 < phantomcircuit> is there a reason that ARM is the fastest travis build?
17:52 < phantomcircuit> that seems odd
17:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
18:01 < jgarzik> builds fewer components IIRC
18:08 < phantomcircuit> jgarzik, sanity check on #6745 ?
18:13 < jgarzik> phantomcircuit, add a unit test to prove it :)
18:16 < phantomcircuit> jgarzik, there's already CRollingBloomFilter tests that validate it's properties
18:16 < phantomcircuit> so im not sure what you mean
18:21 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 244 seconds]
18:27 < gmaxwell> phantomcircuit: not clearing would significantly reduce address propagation, I think? like... if the ratio of addresses to filter size is small enough it's the same as never clearing.
18:29 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:31 < phantomcircuit> gmaxwell, which addresses though?
18:31 < phantomcircuit> real node count, addresses in addrman, or addresses that random peers push out to the network?
18:32 < gmaxwell> well if real node count is low then basically learning about them depends on their being enough bogus addresses to flush out the table... seems like a dumb thing to count on!
18:33 < jgarzik> heh, same comment on the PR
18:35 < phantomcircuit> oh right
18:35 < phantomcircuit> i forgot that PushAddress is what checks addrKnown
18:35 < gmaxwell> :)
18:36 < phantomcircuit> i believe that even with a very low real node/filter size ratio the node would still effectively broadcast it's own address
18:37 < phantomcircuit> for all outbound connections we broadcast our own address
18:37 < phantomcircuit> gmaxwell, hehe also AdvertizeLocal -> AdvertiseLocal
18:39 < phantomcircuit> gmaxwell, the logic in AdvertizeLocal is slightly different from the logic in the "version" message handler, is there a reason for that?
18:39 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
18:40 < phantomcircuit> oh and the logic in the "version" handler ignores fDiscover
18:44 < PRab> https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/prab-key.pgp has expired, but I have created and rolled over to a new key. What is the "proper" way to update this?
18:54 < phantomcircuit> hmm except IsInitialBlockDownload() is going to be true fairly often
19:00 < phantomcircuit> gmaxwell, im thinking that the IsInitialBlockDownload check shouldnt gate AdvertiseLocal in the "version" handler
19:01 < phantomcircuit> (i bet that's mostly the reason why people who up in #bitcoin and ask why they have no inbound connections)
19:10 -!- zooko [~user@2600:100e:b02c:327:4491:4416:b461:1e4e] has joined #bitcoin-core-dev
19:30 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
19:41 -!- zooko [~user@2600:100e:b02c:327:4491:4416:b461:1e4e] has quit [Ping timeout: 240 seconds]
19:44 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
19:45 -!- maaku is now known as Guest18532
19:45 -!- Guest18532 is now known as maaku
19:47 < CodeShark> I would perhaps like to merge code that just moves the IsSuperMajority checks into a separate unit before going full force on version bits. This change would not affect any behavior and only touches main.cpp in very few places. Any objections to this approach?
19:50 < CodeShark> should be easy to review...and easy to rebase against
19:51 < CodeShark> The reason being that if we're going to still use ISM for deployments I'd like to start organizing them better
19:52 < CodeShark> So that when we do the first version bits deployments they are easier to review
19:54 -!- CodeShark is now known as CodeShark_
19:54 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
19:55 < gmaxwell> So it seems someone might have taken my comment about canoniczing transactions to heart, as someone is complaining to me about mutants, and they say that they think the smaller of the mutants is the mutated one.
19:56 < gmaxwell> and that it started for them around midnight utc.
19:56 < gmaxwell> if someone here is doing that, you probably should cut it out. If nothing else, it'll complicate scanning the blockchain and figuring out which wallet software needs to be nagged to produce low-S signatures.
20:02 < CodeShark> if we rebase the current ISM soft forks against my soft forks unit, we can more easily decide how to deploy them later on without having to rebase them again
20:03 < CodeShark> we can either continue to use ISM, we can deploy them one at a time, or several together, or eventually use versionbits
20:06 < rusty> CodeShark I can only really judge after I've seen the result, so use your judgement I guess.
20:08 < CodeShark> rusty, basically https://github.com/bitcoin/bitcoin/compare/master...CodeShark:versionbits but without softforks.h/softforks.cpp
20:08 < CodeShark> and with better structured commits
20:11 < CodeShark> I can rebase 68, 112, and 113 against it
20:11 < CodeShark> as well as 65
20:14 < CodeShark> I just want to see if there are any potential serious objections so I don't waste my time doing it
20:14 < rusty> CodeShark that patch does too much.  There's unnecesary code motion, collapse of variables, and a new return state.Invalid() which I don't see a source for.
20:15 < CodeShark> which code motion are you referring to in particular?
20:15 < rusty> CodeShark ah, this is more than one commit I'm looking at.  One sec/
20:15 < CodeShark> yeah, ignore the commit structure - just look at the final compare
20:15 < CodeShark> I'll be sure to structure the commits to make them easier to review
20:17 < rusty> CodeShark Hmm, IsValidVersion seems like a new concept; I can't see where the equiv code is removed.  Maybe because you commented out rather than removing?
20:17 < CodeShark> it replaces the explicit calls to IsSuperMajority in ContextualCheckBlockHeader
20:18 < CodeShark> I'll be sure to make those movements in a single commit
20:18 < CodeShark> yes, I did comment out what it replaces in main.cpp
20:20 < rusty> Right, so overall it's not too bad, but I would be super paranoid and keep eg. "fEnforceBIP30" var, so diff is minimized.  Then cleanup unnecessary vars at the end.
20:20 < rusty> Make it super bite-size digestible.  People may want a backport...
20:21 < CodeShark> yeah, I want to try to change as little as possible in main.cpp.
20:21 < CodeShark> Eventually I'd like the forks to be clearly visible within the consensus code and structured nicely...but that can wait
20:24 < phantomcircuit> gmaxwell, ha
20:25 < CodeShark> one of the goals, rusty, is to separate the review of BIPs for their features from the review of the deployment strategy
20:26 < CodeShark> would be nice to disentangle the two
20:28 < CodeShark> it would also be beautiful if we could avoid as much rebasing as possible from BIP proposal to BIP deployment
20:29 < CodeShark> we keep getting stuck on stupid crap that continues to delay deployment unnecessarily
20:29 < gmaxwell> versionbits must be backported unless we want to delay it's deployment until 0.12 is the oldest thing we'd backport to. :(
20:29 < gmaxwell> we 'backported' it could be reimplemented, of course.
20:30 < rusty> CodeShark: Agreed, a laudable goal.
20:30 < gmaxwell> I think sipa's initial plan might have been to do that... e.g. using efficient implementation in new code and a 'walks the last 1000 blocks very block' implementation in backports.
20:31 < CodeShark> walking back 1000 blocks every block isn't enough - we need to map state every activation interval in the block index
20:31 < phantomcircuit> gmaxwell, what do you think about setting random bits to 0 in the bloom filter instead of clearing it at a fixed interval?
20:32 < CodeShark> in any case, I'm fine with backporting versionbits itself after 0.12
20:32 < CodeShark> the implementation is the easy part - it's getting it reviewed and acked that's a bitch :p
20:32 < gmaxwell> we're pretty screwed on backport review bandwidth.
20:33 < CodeShark> point is the current proposal won't require backporting
20:33 < CodeShark> or will minimize it considerably
20:33 < gmaxwell> there is always backporting even if the code is unchanged. :)
20:34 < CodeShark> backporting will probably amount to changing a handful of lines in main.cpp
20:34 < CodeShark> or are you also taking into account the proposed code movements for consensus and other stuff?
20:35 < gmaxwell> More that I just mean that most of the 'backporting' work is actually the review to figure out if the changes are really safe in the new context.
20:37 < CodeShark> yes, which is why I'm primarily interested in first merging stuff that will minimize such risks later on
20:37 < CodeShark> it's a horrendous bottleneck
20:37 < CodeShark> lots of people are frustrated
20:39 < CodeShark> a good number of people doing real quantum leap type work on Bitcoin are waiting on changes that are taking forever
20:40 < CodeShark> and it seems that we're wasting a lot of precious expert dev time having them basically repeat the same type of grunt work for each PR
20:40 < CodeShark> (I'm looking at you, sipa)
20:52 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:01 < CodeShark> to be clear, I don't want to sound like I'm complaining - this is not a complaint...I want to help Bitcoin Core be more efficient
21:03 < CodeShark> the dev process, that is
21:12 -!- DocHex [~DocHex@193.28.228.45] has joined #bitcoin-core-dev
21:28 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
22:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
22:17 -!- ParadoxSpiral [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
22:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev
22:36 < GitHub54> [bitcoin] CodeShark opened pull request #6747: Softforks unit (master...softforks_unit) https://github.com/bitcoin/bitcoin/pull/6747
22:47 -!- ParadoxSpiral [~ParadoxSp@p508B968D.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
22:49 < phantomcircuit> that's interesting someone reported "non-canonical ReadCompactSize()" in their error field thing
22:50 < phantomcircuit> see the same thing... on all nodes
22:50 < GitHub176> [bitcoin] paveljanik opened pull request #6748: Rewrite help texts for features enabled by default (master...configure_disable) https://github.com/bitcoin/bitcoin/pull/6748
22:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
23:05 < gmaxwell> http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high    "BIP62 is not currently deployed and we encourage all miners to enforce it as soon as possible."   0_o
23:12 < phantomcircuit> gmaxwell, at this point it seems like it would be best if BIP62 rules were made IsStandard
23:13 < gmaxwell> phantomcircuit: IIRC they aren't even all implemented, and as far as bip62 goes many were only to be applied to higher versioned transactions which don't exist.
23:13 < gmaxwell> we also have relatively low confidence that they're complete.
23:13 < gmaxwell> (like... I don't think anyone has even ever tried implementing them and AFLing to try to get a passing mutant)
23:14 < phantomcircuit> gmaxwell, sure... but it raises the bar a bit
23:15 < gmaxwell> but .. it doesn't. it would have no effect on the current mutations if they're ecdsa based, until people started producing elevated version transactions.
23:18 < phantomcircuit> gmaxwell, mutate to low-s and reject even without higher version numbers as non standard
23:18 < phantomcircuit> it's not a security consideration
23:18 < phantomcircuit> just a nuisance reduction
23:18 < gmaxwell> phantomcircuit: okay, thats the instutionalize the attack thing I mentioned a day ago.
23:19 < phantomcircuit> broken wallets producing high-s are already just as broken as they are now
23:19 < gmaxwell> I'd really like to figure out who is producing high S and nag them to change.
23:19 < gmaxwell> I went to go measure it today but of course the attacks obscure the results. :)
23:20 < phantomcircuit> follow the crumbs of users complaining about weirdness with their wallet :P
23:21 < phantomcircuit> or maybe they'll stop
23:22 < gmaxwell> phantomcircuit: we should probably go write the nuclear canonicize transaction patch at least.
23:22 < phantomcircuit> yup
23:22 < phantomcircuit> gmaxwell, btw im trying to go back and get that trickle logic fixing patch commit ready
23:23 < phantomcircuit> thus my questions from before about AdvertiseLocal
23:33 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
23:33 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
23:35 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
23:37 < phantomcircuit> gmaxwell, well lets see, of the things on the BIP62 list the first is BIP66, right?
23:38 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev