--- Day changed Thu Jan 26 2017 00:07 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 00:29 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep] 00:42 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 00:43 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 00:45 -!- waxwing [~waxwing@113.189.78.210] has quit [Ping timeout: 240 seconds] 00:47 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 00:56 -!- devinbit123 [6a338435@gateway/web/freenode/ip.106.51.132.53] has joined #bitcoin-core-dev 00:58 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f89502306dcf...3f9f9629cc1e 00:58 < bitcoin-git> bitcoin/master 99464bc Suhas Daftuar: net: Consistently use GetTimeMicros() for inactivity checks... 00:58 < bitcoin-git> bitcoin/master 3f9f962 Wladimir J. van der Laan: Merge #9606: net: Consistently use GetTimeMicros() for inactivity checks... 00:58 < bitcoin-git> [bitcoin] laanwj closed pull request #9606: net: Consistently use GetTimeMicros() for inactivity checks (master...2017-01-net-time-comparisons) https://github.com/bitcoin/bitcoin/pull/9606 00:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 01:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 01:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 01:05 -!- waxwing [~waxwing@14.174.34.120] has joined #bitcoin-core-dev 01:05 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:ad18:b2c7:840f:aa9] has joined #bitcoin-core-dev 01:12 -!- shesek [~shesek@bzq-84-110-235-21.cablep.bezeqint.net] has joined #bitcoin-core-dev 01:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:16 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f9f9629cc1e...07421cf2a7cf 01:16 < bitcoin-git> bitcoin/master 5a00659 Russell Yanofsky: [wallet] Clarify getbalance help string to explain interaction with bumpfee... 01:16 < bitcoin-git> bitcoin/master 07421cf Wladimir J. van der Laan: Merge #9613: [wallet] Clarify getbalance help string to explain interaction with bumpfee... 01:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:16 < bitcoin-git> [bitcoin] laanwj closed pull request #9613: [wallet] Clarify getbalance help string to explain interaction with bumpfee (master...pr/getbalance-help) https://github.com/bitcoin/bitcoin/pull/9613 01:16 < bitcoin-git> [bitcoin] laanwj closed pull request #9587: Do not shadow local variable named `tx`. (master...20170119_Wshadow_net_processing) https://github.com/bitcoin/bitcoin/pull/9587 01:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 01:22 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:31 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/10dc58a2aa79...5ac668759ded 01:31 < bitcoin-git> bitcoin/master c36ec71 Cory Fields: depends: qt: disable printer for all platforms, not just osx... 01:31 < bitcoin-git> bitcoin/master 5ac6687 Wladimir J. van der Laan: Merge #9574: [depends] Fix QT build on OSX... 01:31 < bitcoin-git> [bitcoin] laanwj closed pull request #9574: [depends] Fix QT build on OSX (master...fix-osx-depends-build) https://github.com/bitcoin/bitcoin/pull/9574 01:32 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5ac668759ded...fd7021142a7a 01:32 < bitcoin-git> bitcoin/master 8ff8d21 Gregory Maxwell: Send final alert message to older peers after connecting.... 01:32 < bitcoin-git> bitcoin/master fd70211 Wladimir J. van der Laan: Merge #9594: Send final alert message to older peers after connecting.... 01:32 < bitcoin-git> [bitcoin] laanwj closed pull request #9594: Send final alert message to older peers after connecting. (master...send_final_alert) https://github.com/bitcoin/bitcoin/pull/9594 01:42 < gmaxwell> hurrah. 01:47 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 01:51 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9623: fixing typo in README (master...patch-14) https://github.com/bitcoin/bitcoin/pull/9623 01:53 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd7021142a7a...9b4d2673b775 01:53 < bitcoin-git> bitcoin/master de1ae32 Alex Morcos: Exclude RBF txs from fee estimation 01:53 < bitcoin-git> bitcoin/master 9b4d267 Wladimir J. van der Laan: Merge #9519: Exclude RBF replacement txs from fee estimation... 01:53 < bitcoin-git> [bitcoin] laanwj closed pull request #9519: Exclude RBF replacement txs from fee estimation (master...excludeRBF) https://github.com/bitcoin/bitcoin/pull/9519 01:55 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 02:13 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 02:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds] 02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:36 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 02:56 -!- wvr [~wvr@116.red-88-8-192.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 03:05 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.6] 03:05 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 03:14 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 03:14 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 03:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 03:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 03:32 -!- 7F1AAKHX0 is now known as jeremias 03:39 -!- whphhg [whphhg@gateway/vpn/mullvad/x-sfsmehauvysusdgn] has quit [Ping timeout: 248 seconds] 03:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 04:24 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9637: [Qt] fix transaction details output-index to reflect vout index (master...2017/01/qt_vout) https://github.com/bitcoin/bitcoin/pull/9637 04:54 -!- whphhg [whphhg@gateway/vpn/mullvad/x-rgbyuklfozcdlccv] has joined #bitcoin-core-dev 05:18 -!- whphhg [whphhg@gateway/vpn/mullvad/x-rgbyuklfozcdlccv] has left #bitcoin-core-dev ["Leaving"] 05:24 -!- shesek [~shesek@bzq-84-110-235-21.cablep.bezeqint.net] has quit [Ping timeout: 255 seconds] 05:38 -!- shesek [~shesek@bzq-84-110-235-21.cablep.bezeqint.net] has joined #bitcoin-core-dev 05:47 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 05:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 06:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 06:10 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 06:12 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 06:36 -!- Cheeseo [~x@108.61.68.159] has joined #bitcoin-core-dev 06:36 -!- Cheeseo [~x@108.61.68.159] has quit [Changing host] 06:36 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 06:43 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 06:55 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has joined #bitcoin-core-dev 06:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:02 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9638: qa: Actually test assertions in pruning.py (master...Mf1701-qaPruning_try) https://github.com/bitcoin/bitcoin/pull/9638 07:04 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has quit [Read error: Connection reset by peer] 07:04 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has joined #bitcoin-core-dev 07:16 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 07:19 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 07:43 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: ZNC 1.6.3+deb1+trusty0 - http://znc.in] 07:44 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev 08:09 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:11 -!- devinbit123 [6a338435@gateway/web/freenode/ip.106.51.132.53] has quit [Quit: Page closed] 08:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds] 08:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:01 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 09:02 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 09:10 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 260 seconds] 09:12 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 09:28 -!- testtesttest [58cf2c0f@gateway/web/freenode/ip.88.207.44.15] has joined #bitcoin-core-dev 09:55 -!- paracyst_ [paracyst@unaffiliated/paracyst] has quit [Quit: bye] 09:58 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev 10:17 -!- waxwing [~waxwing@14.174.34.120] has quit [Quit: Leaving] 10:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 10:21 -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] 10:23 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 10:24 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has joined #bitcoin-core-dev 10:29 -!- waxwing [~waxwing@14.174.34.120] has joined #bitcoin-core-dev 10:54 < instagibbs> meeting in 6 minutes 10:54 < jtimon> a fast question before the meeting...I did the gitian builds as described in the manual, but didn't sign them yet, it is expected that I create a new gpg key only to sign gitian builds or that I reuse my own? 10:54 < instagibbs> jtimon, I don't know if there's expectation, but it's pretty common yeah 10:54 < instagibbs> make a subkey 10:55 < achow101> jtimon: I don't think it matters. I have been using my own key 10:55 < wumpus> I just use my own 10:55 < sipa> I just use my own 10:55 < instagibbs> wumpus, o_0 crap I recall you using another key that you've signed. Maybe im delusional 10:56 < achow101> instagibbs: maybe you are thinking of the release key? 10:56 < instagibbs> ah, that might be it 10:56 < jtimon> well, my gpg key has 2 subkeys for signing already, but they're in yubikey, not in the VM, I guess I can copy my ~/.gnupg to the VM and then see how I can use the yubikey from the VM, thanks everyone 10:56 < wumpus> though generally it's best to keep things separated, a subkey sounds like the right thing to do, but I haven't got around to figuring out how that gpg functionality works 10:57 < instagibbs> http://pgp.mit.edu/pks/lookup?op=vindex&search=0x90C8019E36C2E964 yes the release key 10:57 < wumpus> yes the releases are signed with a different key, that key only signs releases, not git commits or gitian asserts 10:57 < achow101> jtimon: you can copy the assert files out and sign them 10:57 < instagibbs> I had a key on my VM, then managed to lose it, so not really much better :/ 10:57 < wumpus> yes, I do that too, copy the assert files after build and sign them on another machine 10:58 < instagibbs> achow101, should have thought of that earlier, heh 10:58 < jtimon> achow101: I guess that's another option, but not running ./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml as in https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#build-and-sign-bitcoin-core-for-linux-windows-and-os-x I assume 10:58 < instagibbs> does the gsign stuff just point to the right assert file? 10:58 < instagibbs> ie just copy and do signature like normal, it will validate via gitian script? 10:59 < wumpus> well you still do gsign, but you pass an option to not do the final gpg stop 10:59 < achow101> just gpg --detach-sign normally to sign it. 10:59 < achow101> gsign just makes the assert files AFAIK 11:00 < MarcoFalke> dingding 11:00 < sipa> DONG 11:00 < instagibbs> kk, thanks for explanation, will do for next release 11:00 < wumpus> I don't know by heart what that option is, it used to be passing a dummy 'true' as gpg parameter 11:00 < instagibbs> I'll figure it out 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Jan 26 19:00:21 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00 < jonasschnelli> hi 11:00 < instagibbs> (actually would be a useful optional step in gitian guide) 11:00 < wumpus> and yes on thesigning side you do gpg --detach-sign, no need for gitian there at all 11:00 < wumpus> yes the gitian guide mentions signing externally but I'm not sure it says how to do that 11:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs 11:01 < instagibbs> oops, https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#signing-externally 11:01 < instagibbs> jtimon, ^^ ok now meeting sorry 11:01 < kanzure> hi. 11:01 < wumpus> proposed topics? 11:02 < jtimon> instagibbs: np, got good answers already 11:02 < sipa> if people don't shoot me for it, i'd like to briefly bring up coding style 11:02 < wumpus> bleh 11:02 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 11:03 < jtimon> if there's no other topic, I don't see why not 11:03 < instagibbs> how about just a grazing flesh wound 11:03 < wumpus> but yes there's no other proposals so go ahead 11:03 < MarcoFalke> If morcos is around, we could make a short topic on how to get the priority patch merged. (Seems to bit rot fast) 11:03 < wumpus> #topic coding style 11:04 < sipa> it seems that we're not really asking people to stick to particular coding style, and that sometimes leads to unclarities "what style should i use here?" 11:04 < BlueMatt> ugh 11:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Client Quit] 11:04 < morcos> i'm here.. i'm happy to worry about that after 0.14 11:04 < MarcoFalke> just use clang-format-diff.py *hides* 11:05 < jonasschnelli> MarcoFalke: +1 11:05 < instagibbs> sipa, I copy the code around me :P 11:05 < jtimon> the answer is https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format no? 11:05 < sipa> and i think that the "mimick the surrounding code" advice we've been following is a bad idea 11:05 < wumpus> I don't really see the point in spending more energy on this 11:05 < sipa> it doesn't actually help in making the codebase converge (which i think is goal) 11:05 < jonasschnelli> I once proposed that, but everyone was against that. A CI check for clang style. We can still accept it... and could be something different then travis. 11:05 < jtimon> but yeah, since it's not done automatically project wise I often violate it without noticing 11:05 < MarcoFalke> Just format the diff on every patch and we will converge eventually. 11:06 < sipa> i'm not suggesting we go fix everything at once 11:06 < wumpus> I think mimicing the surrounding code is a good thing, usually, as long as you don't introduce really crappy looking lines well I won't hold up merging on a few code style nits 11:06 < morcos> wumpus: i do think it would be nice if we were at least slowly converging on a common code style... i think we are making small progress.. for instance now i know to always brace my if's and i don't mind if someone points out that i forget it 11:06 < jtimon> MarcoFalke: IIRC there was a python script to do that automatically 11:06 < BlueMatt> jonasschnelli: I'm opposed to a CI check for clang style...I'm in favor of a bot which auto-opens a pr which fixes clang style on recently-broken PRs 11:06 < wumpus> morcos: yes, always using braces makes sense from a security/correctness point of view 11:06 < MarcoFalke> jtimon: Yes I commited those :) 11:06 < jtimon> or something similar, but I've never used it 11:06 < morcos> what is annoying is when you don't know what you're supposed to do, and then something is pointed out to you and you feel like its just a difference in taaste 11:07 < sipa> right - my goal is to make the codebase converge 11:07 < wumpus> but some other things, meh 11:07 < BlueMatt> sipa: yes, that would be nice 11:07 < wumpus> it usually *is* a difference in taste 11:07 < sipa> not necessarily fast, and not necessarily to whatever my own personal preference is 11:07 < jtimon> MarcoFalke: right, so I think if we all use that, as you say we will eventually converge (or be close enough that is not a big deal to do the remaining stuff all at once) 11:07 < sipa> but i'd like to get an agreement that the goal is converging 11:07 * BlueMatt votes for coding-style-recent-pr-fixup bog 11:07 < BlueMatt> bot 11:08 < wumpus> as I said, I don't really see the point of spending much energy on this. There are tons of real issue 11:08 < BlueMatt> that way none of us have to think about it, but it still happens :) 11:08 < morcos> i'm +1 on converging to someone's taste. i don't much care whose, as long as there is an answer that doesn't depend on who you ask 11:08 < wumpus> I don't want to see even more 'massage around a few characters idly' pulls 11:08 < jtimon> what about just a check in travis or something? 11:08 < wumpus> no. 11:08 < MarcoFalke> jtimon: We don't want travis to fail due to style 11:08 < paveljanik> I'm in favour of slow non-forced (no-CI) convergence. 11:08 < wumpus> travis should check correctness 11:08 < instagibbs> Can we at least have a cultural push towards one? I don't care which. 11:08 < wumpus> if travis fails due to style, it will always be broken, believe me 11:09 < sipa> instagibbs: +1 11:09 < BlueMatt> yes, no travis-says-no-for-garbage-reasons 11:09 < MarcoFalke> But we might add a non-voting other-than-travis ci, if that is possible? 11:09 < wumpus> I don't want to block pulls on stupid style issues 11:09 < BlueMatt> wumpus: yes, very much that 11:09 < wumpus> there are already enough valid reasons to hold up pulls for months 11:09 < wumpus> please 11:09 < wumpus> focus on important stuff 11:09 < jtimon> wumpus: right, it would be only on style on the newly modified code, but yeah, it seems it could fail when we don't want it to 11:10 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 11:10 < jtimon> anyway, the bot could just nit open prs instead of fixing things by himself 11:10 < BlueMatt> the only coding style issue I'd be ok with travis complaining about is bad indentation 11:10 < morcos> sipa, or anyone else that has an opinon on coding style.. if you'd like to get people to move to your style on any specific thing, i think you need to get your request merged to developer-notes 11:10 < BlueMatt> because that leads to bugs 11:10 < sipa> maybe what i'm after is being able to ask people (as a non-blocking nit, even) to fix style issue, without it being seen as "forcing your personal opinion" 11:11 < wumpus> I say if there's use of coding style that is known to introduce bugs (such as unbraced conditionals) there's a point to pointing it out 11:11 < morcos> if its in there, i think its fair game for pointing out not meeting it... if its not in there.. well come on 11:11 < BlueMatt> jtimon: people already complain about endless nits when they show up for the first time to contribute...I'm ok with my own prs getting that, but not people trying to do one-offs 11:11 < sipa> morcos: of course, only for things in the style guide 11:11 < wumpus> morcos: yes, it should certainly be documented in that file 11:11 * jtimon wonders if this is the right time to indent CheckTxInputs 11:11 < wumpus> if it's not in there there's no basis for pointing it out 11:12 < morcos> we are all talking about NEW code... but jtimon brings up a good point... 11:12 < sipa> a move-only commit should probably not change style 11:12 < morcos> for instance i have a couple of recent PR's that add braces without changing indentation.... 11:12 < sipa> about that: 11:12 < wumpus> eh, indeed, that makes it harder to check whether it's mov only 11:12 < sipa> git diff -w, git blame -w, git show -w, ... 11:13 < morcos> i thought thats what people preferred... but i'm happy to add the indentation if people can figure out how to ignore the white space changes 11:13 < gmaxwell> changing style though should result in the same object files. 11:13 < sipa> and even github supports whitespace ignoring diffs, add ?w=1 to the URL 11:13 < wumpus> gmaxwell: definitely 11:13 < morcos> ok... good wiht me.. i just thought people wanted differently b/c of similar examples in the codebase 11:13 < BlueMatt> sipa: you meant -b 11:13 < wumpus> gmaxwell: that means adding/removing no empty lines though 11:13 < wumpus> gmaxwell: because line numbers 11:13 < instagibbs> do we have a style guide already? 11:13 < instagibbs> "if" braces even 11:14 < wumpus> instagibbs: you don't know? 11:14 < jtimon> yeah, regarding CheckTxInputs I believe I was asked to wait after moving it for indenting ages ago or something, but yeah, didn't know -w and that's more reason not to wait for anything (specially moves that may never happen) 11:14 < BlueMatt> wumpus: I think lots of people dont... 11:14 < gmaxwell> I think we should avoid changing indents spairingly. And then fix it not long after. 11:14 < sipa> instagibbs: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md 11:14 < instagibbs> wumpus, I'm here to ask the dumb questions 11:15 < gmaxwell> the developer nodes style guide isn't much of a style guide (not a complaint), and its more of one recently, but I don't normally consider it the place to go to figure out how to format something. :) 11:15 < wumpus> BlueMatt: we refer to it in CONTRIBUTING.md, which automatically gets linked if you submit a PR 11:15 < wumpus> gmaxwell: it's not supposed to have a lot of formatting guidelines, just basic ones 11:15 < sipa> gmaxwell: i'm perfectly fine restricting my style nits to things that are in that file 11:15 < BlueMatt> wumpus: I believe only for issues - I've never seen it for PRs 11:15 < BlueMatt> but, ok, fair 11:16 < wumpus> it mentions the "always use braces" though 11:16 < jtimon> right, I believe we should try to avoid style nits that we don't have documented 11:16 * BlueMatt thinks the endless "add braces here" comments in the past month got kinda annoying for a while 11:16 < wumpus> definitely. In general please try to not cloud out serious discussion with lots of style nits 11:16 < BlueMatt> agree with them, but annoying 11:16 < jonasschnelli> wumpus: thats a very good point 11:17 < wumpus> BlueMatt: that's my point ^^ 11:17 < jtimon> and by documented I'm fine counting https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format 11:17 < BlueMatt> wumpus: yes, just agreeing, I suppose :) 11:17 < MarcoFalke> We should just raise awareness that there is a script to do the formatting for you. 11:17 < sipa> yeah, no point in "add braces here" and "and here!" and "and here also!" comments all over the place, i guess 11:17 < MarcoFalke> No need to spam pull requests 11:17 < gmaxwell> Peopel should say if it bothers them, but my expirence is that small things like that improve moral in development teams. It's an oppturnity to help each other which is very easy and clear. Not "please totally redesign your patch". :) 11:17 < gmaxwell> people* 11:18 < jtimon> MarcoFalke: right, althought the bot that runs the script for you and complains in your PR sounds like a good idea to me 11:18 < gmaxwell> At least I find it gratifying to go, fixed, fixed, fixed, fixed.. and now the patch is awesome hurray and thanks for your help. :) 11:18 < sipa> enough said on the topic, as far as i'm concerned 11:18 < instagibbs> sipa, feel free to propose a "non blocking, non-nitting" style 11:18 < instagibbs> :P 11:18 < MarcoFalke> #action PSA Use clang-format-diff.py before submitting a patch, whenever possible. 11:18 < wumpus> gmaxwell: sure, as long as it's not overly pedantic, and doesn't continue time after time. e.g. you're just about to merge something and a new screenful of style nits appears 11:19 < gmaxwell> MarcoFalke: is there instructions on that? also does it know about our new brace requirements? 11:19 < wumpus> morcos: good advice I suppose, should go into CONTRIBUTING.md 11:19 < sipa> wumpus: so how about treating style always as non-blocking (for the person deciding to merge) 11:19 < MarcoFalke> #action fix clang-format https://github.com/bitcoin/bitcoin/pull/9506#issuecomment-271727718 11:19 < jtimon> we can always ignore the bot in certain cases if it makes sense 11:19 < MarcoFalke> gmaxwell: There should be a doc in /contrib/dev-tools, no? 11:20 < wumpus> yes there is documentation on how to use it 11:20 * wumpus wonders if there is still so much differnce between clang versions, for recent versions 11:20 < gmaxwell> MarcoFalke: I dunno, never used that tool before. it's not mentioned in contributing.md. 11:20 < wumpus> I mean in how clang-format formats 11:21 < jtimon> right, we need to use the same version 11:21 < gmaxwell> yea, I'm willing to install a specific version of clang for this-- as most of us should be... but just something to keep in mind for random contributors from the interwebs. 11:21 < MarcoFalke> wumpus: Last time I checked there were no diffs, but it was a year ago or so. 11:21 < wumpus> gmaxwell: well it's very possible that it stabilized, it's less important for format-patch than when requiring a reformat of the whole source, then it will oscillate :p 11:22 < MarcoFalke> But it should not matter for 99.9% of the code. 11:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds] 11:22 < wumpus> anyhow, other topics? 11:23 < sipa> how are we on 0.14 bugs? 11:23 < gmaxwell> All bugs are features, hurray. 11:23 < morcos> i have one more that needs tagging 0.14.. and i think sdaftuar has 1-2 coming 11:24 < wumpus> #topic bug-fixing for 0.14 11:24 < morcos> they are all kind of minor fixups for bumpfee or replacement type stuff... mostly edge cases.. nothing serious 11:24 < MarcoFalke> morcos: I think the one you want to tag is more a feature than a bug fix. At some point we need to draw the line and release. 11:24 < morcos> please tag #9615 11:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub 11:24 < MarcoFalke> But the one that is tagged right now should be merged as bug fix 11:25 < achow101> I have a bug-fix (I think) for decoderawtx rpc 11:25 < morcos> MarcoFalke: well its a bug fix b/c if we ever do a release without having a more conservative wallet incremental fee, then we are screwed for ever incrementing it 11:25 < morcos> this has bit us in the past with dust fees 11:25 < wumpus> tagged 11:25 < jtimon> reminder, there's currently 6 open prs for 0.14.0: 9638 9626 9622 9609 9589 9108 11:25 < morcos> its also really simple 11:26 < morcos> i also mention in there that i think we should increase the incremental fee... that coudl be a topic.. but i realize people might not want to do it this close to release, but at least worth discussing it as a general idea and why.. 11:26 * BlueMatt is waiting on (needs to review 9609) and then run things in helgrind again...will generate lots of std::atomic changes 11:26 < BlueMatt> but they should all be minor/trivial 11:27 < gmaxwell> :-/ 11:27 < morcos> but given that it might already be close to needing to be raised, we have to do 9615 11:27 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370 11:27 < MarcoFalke> What if we want to increment it to 6000 satoshis in two years, then 0.14 will "fall off" regardless. 11:27 < gmaxwell> BlueMatt: if there are helgrind results I am doubtful that sprinking atomics everywhere is usually the right solution. For some things like flags it can be... but if we're hitting helgrind errors it means we've gotten the locking wrong. 11:28 < cfields> whoops, lost track of time. here. 11:28 < MarcoFalke> But I get your point, I just think it is not a blocker. It could also go into 0.14.1 11:28 < morcos> MarcoFalke: yes.. but that is something we will keep in mind if ever changing the default... is how many old versions will become less than optimal.. i don't know any better way to do it... there is a tradeoff 11:28 < BlueMatt> gmaxwell: shit like CNode::copyStats...should be trivial, is only used in (effectively) debug info, doesnt matter much 11:28 < BlueMatt> gmaxwell: but, yes, otherwise agreed 11:28 < morcos> but if it goes in 0.14.1 then 0.14.0 could become broken for bumpfee within a few months... that seems bad! 11:28 < wumpus> gmaxwell: tend to agree, doesn't seem like making everything atomic is the proper way to solve concurrency issues - it just shuts up the warnings, without addressing the root cause 11:29 < BlueMatt> wumpus: thats why I never did a pile of PRs to do it :p 11:29 < gmaxwell> morcos: oh incremental is just the thing that bumpfee uses but not the acceptance policy (behind on the naming since the split) 11:29 < wumpus> that's like putting (unsigned) everywhere to shut up comparisons between signed/unsigned errors without looking at the ranges 11:30 < MarcoFalke> gmaxwell: Yes, the goal is to split the wallet default and the relay default. 11:30 < wumpus> BlueMatt: yes for statistics it seems harmless 11:30 < instagibbs> morcos, I didn't expect people to button-mash bumpfee, but maybe I'm wrong on usage patterns 11:30 < morcos> gmaxwell: incremental is the policy, #9615 introduces a wallet incremental which is higher than the default incremental to future-proof... not configurable, but maxed with actual incremental 11:30 < gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub 11:30 < gmaxwell> I would agree that bumpfees behavior should be more conservative. (IMO bumpfee should always increase at least multiple of the prior feerate, not just the incremental, in order to give log() bumps at worst) 11:30 < cfields> wumpus: many are net things that have been around forever (CNodeStats). I have some ideas in mind for fixing them post-0.14, but I think the changes will end up being too big for 0.14 11:30 < cfields> (re atomics) 11:30 < instagibbs> In the case of "I just did it, or est feerate is same, I just want higher" this concern seems real 11:31 < wumpus> cfields: right 11:31 < morcos> instagibbs: i think its reasonable to expect stuck transaction problems might get considerably worse over the next 6 months... an improved fee estimation is definitely needed... but its certainly possible bumpfee will be important. 11:31 < wumpus> cfields: forgot for a minute that the topic is fixes for 0.14 :) 11:31 < cfields> wumpus: yes, otherwise i'd be yelling about s/int/atomic_int/ too, for sure :) 11:32 < morcos> gmaxwell: it by default does a new estimatefee... it just max's that with a multiple of the increment above to make sure it will pass policy 11:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 11:33 < gmaxwell> morcos: right, I think it should also max with a e.g. 10% increase... so that you don't ever have the issue of needing hundreds of bumps to span a plausable range. I'm in the weeds here though. 11:33 < morcos> this is the first time we're releasing bumpfee... i think we've come up with a lot of minor improvements recently and i know its a lot to keep track of.. but it doesn't make sense to me to release it for the first time with sub-optimal behavior if there are known simple fixes 11:35 < morcos> gmaxwell: yeah.. maybe.. but that could be an improvement for the future... i just want to make it so the old version doesn't run into a problem where its txs aren't even accepted by peers mempools if we change default policy (which i think should be another topic) 11:35 < wumpus> well, I'm happy that at least we've merged it for 0.14, makes sense to improve it where possible before the release, if we have clear ideas of course 11:35 < gmaxwell> (well the observation that a multiplictive increase is necessary and sufficient to span an arbitary range with log() bumps is not a new observation. ... I believe it's mentioned in the RBF FAQ.) 11:36 < morcos> yes to be clear i'm not opposed to anyone else doing gmaxwell's idea before release.. i jsut want to do at least what i've suggested 11:36 < gmaxwell> Someone should take a look at what green address and electrum are doing here to see if they've caught anything we've missed-- both have bumping in production. I volunteer to check greenaddress. 11:36 < morcos> i mean this ties into my other topic 11:37 < morcos> when i heard petertodd talking about how he just presses bumpfee in a loop (or maybe he does his own version, but in the future other people might just press bumpfee) 11:37 < morcos> it occurred to me we are allowing WAY too much relay for 1 tx being mined 11:38 < morcos> so gmaxwell is right that there are 2 ways to improve upon this... 1) raise incremental relay rate required... and 2) make it so the behavior of our own code doesn't cause this ridiculous relay iteration by default if people want to do periodic bumping to get confirmed 11:39 < gmaxwell> minrelayfee is minrealy fee, replacement is orthorgonal-- you can use X bytes of relay for exposing yourself to Y fee either way. 11:39 < morcos> i don't know if it's important to do 1 or 2 before 0.14.. i don't care strongly.. but i do think they are probably both needed improvements 11:39 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer] 11:39 < BlueMatt> gmaxwell: that is no longer true (I mean it is in principal, but not in code) 11:39 < BlueMatt> min relay fee is min(minRelayFee, minReplacementFee) 11:40 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev 11:40 < gmaxwell> the fact that my mempool is sitting at 14MB of data right now suggest the relay fee is not too low, though I wish it were. 11:40 < morcos> that's only b/c of good behavior 11:41 < gmaxwell> uh what? the whole security design of RBF is based on the replacement being the actual in-use min-relay fee. 11:41 < BlueMatt> gmaxwell: ok, hold on...there is still a min relay fee which is used for bumping, that didnt go away, its just a different CLI flag name now 11:41 < morcos> so gmaxwell the new design is that incrementalrelayfee is the number that you feel like should be the minimum cost to relay 11:41 < gmaxwell> morcos: the operative question is would increasing it cut of transactions that would otherwise confirm in a not crazy amount of time. And it would, I think? 11:42 < morcos> definitely every byte transmitted one way or the other would have to pay at least that 11:42 < morcos> minrelaytxfee in initparamaterinteraction has to be at least that.. but could optionally be higher 11:43 < morcos> but my point is that number is actually really really low if you compare it to the "useful" relay rate which is much closer to 50 sat/ byte (as opposed to 1) and allowing somoene to relay 50 times just to keep bumping from 1 to 50, kind of sucks 11:44 < gmaxwell> I don't see why you're talking about bumping. 11:44 < morcos> gmaxwell: i mean i guess if we raised it from 1 to 5, then yes some small amount of txs that paid between 2-5 would have to now pay 5... but raising it to 2 would basically harm nothing and cut down on the potential to relay lots and lots of times for fun 11:44 -!- instagibbs_ [640f7203@gateway/web/freenode/ip.100.15.114.3] has joined #bitcoin-core-dev 11:45 < gmaxwell> They can also relay 50 transactions, the bumping is orthorgonal. I would say 50 that probably won't confirm, even avoiding the fee, but thats not actually true. (or if it's true and I didn't notice, then yes sure we should up the increment) 11:45 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 11:46 < gmaxwell> okay, I haven't measured carefully, if 2 is the realistic floor what what gets confirmed then thats what the value should be. 11:46 < morcos> btwn 1-2 might not ever confirm. my best guess is you have 1 chance in 3 ... >2 would i agree eventually confirm 11:46 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 255 seconds] 11:46 < gmaxwell> sounds like at a very minimum we should make an estimate now of what will realistically confirm and make the wallet do that. 11:47 < morcos> anyway this is the next topic.. (topic: are we charging adequately for relay) i just wanted to start a discussion about it. i don't feel it has to be changed for 0.14. but the fact that its even a consideration is why i want to future-proof the wallet for 0.14 (the change made in #9615) 11:47 < gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub 11:48 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has quit [Client Quit] 11:48 < wumpus> #topic are we charging adequately for relay? 11:48 < gmaxwell> morcos: we should change wallet behavior in advance of changing relay behavior. 11:49 < gmaxwell> so if we think relay behavior should change to 2-3 we should change wallet to that now. these are all insignificant amounts. 11:49 < morcos> i think we might be done with that topic too... i think greg's point is if someting close to the low end of relay fee can still get confirmed a non-trivial amount of the time.. then relay cost isn't too high. i agree this seems to be true.. maybe we could raise from 1 to 2.. but it seems insufficiently motivated to push through now 11:50 < gmaxwell> 2s/b is a half cent for a median size txn at $1000/btc. 11:50 < morcos> gmaxwell: yes... wallet change in 9615 is to pay at least 5 greater than transaction it is replacing... small enough not to hurt but enough to be in advance of future changes 11:52 * BlueMatt got 0.1 s/b confirmed last weekend pretty easily, so I think it is premature to be discussing bumping it 11:52 < BlueMatt> (not proposing we lower it, but blocks are very often not full at all) 11:52 < gmaxwell> as far as what gets confirmed, I think we have hangover legacy of many miners having turned up minrelay fee before there was mempool limiting and before createnewblock was fast. 11:54 < gmaxwell> So it may be prudent to first rename the arguments to cause people to reconsider or go back to the defaults... before concluding that 1s/b will not confirm. doubly so with the fact that segwit may well put the fee behavior back in a disfunctional state (though perhaps thats also an argument to increase the default minimum relay fee in advance of it.) 11:54 -!- emzy [~quassel@raspberry.emzy.de] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 11:55 < instagibbs_> 5 minutes 11:55 < BlueMatt> gmaxwell: thats fair 11:55 < BlueMatt> I'm not against renaming the relay fee options 11:56 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-dev 11:56 < morcos> There is basically no reason to use minrelaytxfee at all anymore... 11:56 < morcos> in fact in my remove priority PR i make it so you can set it to 0 11:57 < wumpus> no conceptual problems with ti, but it's too late to make option changes for 0.14 11:57 < morcos> but incrementalrelayfee controls cost of relay and blockmintxfee controls orphan risk 11:57 < morcos> so we can just advise in the 0.14 release notes that it is not a necessary DoS protection to set minrelaytxfee at all any more 11:57 < gmaxwell> I doubt its much correlated with orphan risk at all now due to Fibre and BIP152. 11:57 < morcos> (not to mention mempool limiting and the mempool min fee) 11:57 < instagibbs_> People will have to intervene to turn on walletrbf, I don't think a default tweak is a bridge too far as well. 11:58 < gmaxwell> Lets announce in the release notes that the option will be renamed, and encourage people to remove it. 11:58 < BlueMatt> if you're using FIBRE (some pools still arent), there is 0 correlation.... 11:58 < wumpus> +1 gmaxwell 11:58 < morcos> gmaxwell: sounds good. 11:59 -!- emzy [~quassel@raspberry.emzy.de] has quit [Changing host] 11:59 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev 11:59 < gmaxwell> BlueMatt: not for 0.14 but someone really ought to implement the createnewblock tweak to skip very recently recieved low fee txn.. which does have a relationship to orphan risk. I think doing something fairly dumb would still be a big improvement. 11:59 < wumpus> #endmeeting 11:59 < lightningbot> Meeting ended Thu Jan 26 19:59:55 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 11:59 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.html 11:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.txt 11:59 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.log.html 12:01 < instagibbs_> gmaxwell: do you think this is part of the unseen transactions that CB misses from mempool? 12:01 < sipa> i assume so 12:02 < BlueMatt> gmaxwell: yea, i think we've talked about this before...needs to happen 12:02 < gmaxwell> instagibbs_: oh absolutely, with the extra pool there should only be two remaining sources of misses-- things that just didn't propagate yet (those), and miners with 'priority service'. 12:02 < morcos> gmaxwell: -blockrecenttxminfee ? 12:02 < morcos> I would like a baker's dozen min fees 12:02 < instagibbs_> gmaxwell: yes OOB was my other thought 12:02 < instagibbs_> wasn't sure of proportion 12:03 < instagibbs_> high fee not prop vs low fee not prop vs low fee + OOB 12:03 < sipa> or a conversion factor between time and feerate... higher fee things may be worth taking a slight propagation risk for 12:03 < gmaxwell> morcos: sounds fine to me. could be set pretty high, my perspective is that the only reason to not deny very recent txn completely is that someone may notice themselves missing a large fee and feel regret. :) 12:04 < gmaxwell> I collected data for that, measuring the mempool consistency between a node in europe, califorina, and au. Somewhere I have graphs. 12:04 < instagibbs_> miners may be willing to miss out on a single reasonble fee tx, but maybe not a 150BTC one ;) 12:04 < gmaxwell> instagibbs_: dunno the propotion but we can't do anything about OOB. 12:05 < sdaftuar> we could prefill the compact block 12:05 < gmaxwell> yea, I don't want to create an incentive to go rip out or deactivate a good feature because you missed a 1BTC fee. anyways, I did math on a orphaning mediated rational setting and came up with some number that was significantly higher than typical fees at the time, but I think actually lower than typical fees now. 12:06 < gmaxwell> sdaftuar: yes, 0.15 feature, we needed extra in first-- since the best scheme I'm aware of for prefill is to use what missed on transmission to you... it was important to get your own logic as smart as possible first. 12:07 < sdaftuar> sure, makes sense 12:07 < sdaftuar> these createnewblock changes are just hard to reason about without real-world data on the various tradeoffs 12:08 < gmaxwell> well I collected data that IIRC basically said everyone was consistent after about 10 seconds. I don't even think never including transactions until you've had them for 10 seconds would be bad... except for the risk that it might enrage someone due to missing a high fee txn. 12:09 < gmaxwell> so my thought was just having a dumb limit, ignore txn newer to you than ten seconds unless the fee rate is 'high'. ten seconds is an insigificant enough delay to mostly not care about it. 12:10 < gmaxwell> new measurements should be performned I guess. 12:10 < sdaftuar> ok, maybe that is simple enough to just do then 12:10 -!- arubi [~ese168@bzq-79-181-103-90.red.bezeqint.net] has joined #bitcoin-core-dev 12:10 -!- arubi [~ese168@bzq-79-181-103-90.red.bezeqint.net] has quit [Changing host] 12:10 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 12:10 < sdaftuar> my initial thought was, maybe we should include a small recent medium fee tx that we can prefill without eg using more packets on the wire for the compact block 12:11 < sdaftuar> but taht's definitely too complicated :) 12:11 < gmaxwell> yea, and who cares that you delay a typical fee by ten seconds? you'll include another typical fee instead. :) 12:11 < sdaftuar> right 12:11 < instagibbs_> gmaxwell: is your thought to also prefill(after complete misses) the extra pool hits if space allowed? 12:12 -!- arubi [~ese168@unaffiliated/arubi] has quit [Client Quit] 12:12 < gmaxwell> instagibbs_: no, I would propose we see how many we missed, if it's too many do no prefill. If it's not, prefill only our misses... assumption is that the peers mempool is the same as ours. 12:12 < instagibbs_> you're also assuming there that extra pool is same(maybe right) 12:12 < gmaxwell> if we missed too many, assumption is they're going to take a RTT regardless, don't waste bandwidth on prefill that the're going to get three copies of. 12:13 < gmaxwell> instagibbs_: I am. well extra pool unlike mempool is actually convergent.. (or at least ignoring its size limit it is) 12:13 < gmaxwell> e.g. given time extra pools become more similar while due to rbf-acceptance-threshold and doublespends the mempool is not. 12:13 < morcos> wait, so it won't count as a miss if it was in our extrapool right 12:13 < gmaxwell> Yes. 12:13 < instagibbs_> correct 12:14 < gmaxwell> We could expirement with things but "peer is the same as us" is a really good first approximation that will be hard to beat. 12:15 < gmaxwell> it's also important to not overdo the prefill: the prefill is in the same message as the CB so any size added to the prefill adds delay to the CB even if the peer could perform a prefill-less reconstruction. 12:15 < sdaftuar> huh, i hadn't thought about extrapool convergence before. will it really converge, given that we don't relay the things in it? or are you saying that extrapool+mempool taken together should converge? 12:15 < gmaxwell> sdaftuar: extrapool+mempool will converge where mempool alone will not. 12:16 < instagibbs_> sdaftuar: you relayed them in the past tho 12:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 12:16 < sdaftuar> instagibbs_: not orphans 12:16 < gmaxwell> Subject to all sorts of messy bits of reality... 12:16 < instagibbs_> sdaftuar: mm yes 12:16 < gmaxwell> but once you have a conflict in your mempool you'll never accept the alternative no matter how many times it gets given to you. 12:17 < instagibbs_> that's an arg to prefil orphans 12:17 < gmaxwell> extrapool isn't like that. :) "Give me your tired, your poor, 12:17 < gmaxwell> Your huddled masses yearning to breathe free" 12:17 < instagibbs_> but maybe same peers are passing to you, *shrug* 12:18 < gmaxwell> in any case before BIP152 spec was done, I tested prefill based on misses and it cut the rount trip rate by a ton... but it was on a dumb test network. debug=mempool logs enough to let you make the measurement with existing nodes. 12:19 -!- buddhaghosa [chatzilla@gateway/vpn/mullvad/x-mnixuxrcomrvqeto] has joined #bitcoin-core-dev 12:19 < gmaxwell> e.g. if there are IIRC <5 missing it logs the missed txids. so you can compare that on a pair of nodes to see how many RT it would eliminate. 12:20 < BlueMatt> gmaxwell: that was with an infinte extrapool, no? 12:20 < BlueMatt> (well, effectively infinite by looking back through debug.log) 12:21 < instagibbs_> how do you specify two debug flags, mempool and cmpctblock? 12:21 < instagibbs_> btw 12:21 < instagibbs_> without doing debug=1 12:22 < sipa> -debug=mempool -debug=cmpctblock ? 12:22 < BlueMatt> -debug=mempool -debug=cmpctblock 12:22 < sipa> same as with all multiarg 12:22 < BlueMatt> it is confusing that some of our args are multiarg some of them are replace-last-arg 12:23 < instagibbs_> oh mapmultiArgs, yes 12:23 < instagibbs_> should have tried 12:25 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 12:27 < gmaxwell> BlueMatt: yes. 12:37 -!- instagibbs_ [640f7203@gateway/web/freenode/ip.100.15.114.3] has quit [Ping timeout: 260 seconds] 12:58 < bitcoin-git> [bitcoin] sdaftuar opened pull request #9640: Bumpfee: bugfixes for error handling and feerate calculation (master...2017-01-bumpfee-error-cleanup) https://github.com/bitcoin/bitcoin/pull/9640 13:04 -!- Kexkey [~kexkey@23.227.207.22] has joined #bitcoin-core-dev 13:04 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 13:26 -!- MarcoFalke [~marco@host112-2.natpool.mwn.de] has left #bitcoin-core-dev [] 13:28 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds] 13:38 -!- waxwing [~waxwing@14.174.34.120] has quit [Ping timeout: 248 seconds] 13:57 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 13:57 -!- aguycalled [~alex@37.120.37.13] has joined #bitcoin-core-dev 14:06 -!- Kexkey [~kexkey@23.227.207.22] has quit [Ping timeout: 248 seconds] 14:14 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 14:23 -!- shesek [~shesek@bzq-84-110-235-21.cablep.bezeqint.net] has quit [Ping timeout: 260 seconds] 14:29 -!- wvr [~wvr@116.red-88-8-192.dynamicip.rima-tde.net] has quit [Quit: Leaving] 14:37 -!- shesek [~shesek@bzq-84-110-235-21.red.bezeqint.net] has joined #bitcoin-core-dev 14:54 -!- ptk [580923c2@gateway/web/freenode/ip.88.9.35.194] has joined #bitcoin-core-dev 14:54 < ptk> hi 14:55 < ptk> can you help me? 14:55 < ptk> # Build the library and install to our prefix cd db-4.8.30.NC/build_unix/ # Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime ../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX make install 14:55 < ptk> This don't work 14:56 < ptk> Ask me for the doc 15:02 < ptk> #join inversores 15:02 -!- ptk [580923c2@gateway/web/freenode/ip.88.9.35.194] has left #bitcoin-core-dev [] 15:30 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:34 < jtimon> mhmm, reading https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.14.0-Release-notes#opt-into-full-rbf-when-sending 15:34 < jtimon> I thought full RBF was the original version without opt-in or anything 15:35 -!- waxwing [~waxwing@14.174.34.120] has joined #bitcoin-core-dev 15:42 < luke-jr> indeed, that should be rephrased 15:45 < sipa> jtimon, luke-jr: agree it may be confusing, but that's the name that has always been used (see BIP 125, even) 15:45 < luke-jr> sipa: is it any worse if we leave off "full"? 15:45 < sipa> it's full RBF as opposed to condition RBF (which is only replacing things when all outputs are maintained) 15:45 < jtimon> oh, I see 15:46 < sipa> luke-jr: i think we can drop the 'full', yes 15:46 < sipa> just pointing out the history behind it 15:47 < jtimon> yeah, thanks, and ack on dropping the full, it may confuse someone else and it reads well without it 15:49 < gmaxwell> need to stop saying RBF and just start saying BIP125 replacable. So much more clear. :P 15:51 < jtimon> right 16:07 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 16:10 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Remote host closed the connection] 16:10 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 16:13 < jtimon> another question about gitian, why are there signed and unsigned builds for win and osx in https://github.com/bitcoin-core/gitian.sigs ? (according to the guide it seems I should build and sign the unsigned ones) 16:13 < sipa> jtimon: because the signed ones require a key that is not public 16:14 < sipa> so people can build the unsigned one, compare results, then the person with the key can produce the detached signatures 16:14 < sipa> and then people can build the signed one from the earlier unsigned result plus downloaded detached signature 16:15 < gmaxwell> I am proud to work with people who come up with such slick procedures. :) 16:16 < jtimon> why do the signed ones require a key that's not public? 16:17 < gmaxwell> jtimon: signed in this case refers to the windows and apple code signing keys. 16:17 < gmaxwell> which are used to prevent ugly warning boxes on those OSes. 16:17 < gmaxwell> to anyone who pays the piper. :P 16:18 < jtimon> ohh, right 16:20 < jtimon> I'm having problems building osx, I think I did all well, https://0bin.net/paste/U+Sqgot+Xk0VO-kL#cQl5R4xNHgCBRNxC5IoHZd7aW-dPJKTNO2ghEPVm0rz 16:21 < sipa> jtimon: you don't have the MacOSX SDK 16:21 < sipa> tar: MacOSX10.11.sdk.tar.gz: Cannot stat: No such file or directory 16:22 < jtimon> oh, I thought it would download it by itself or something, I see 16:22 < sipa> no, it can't, license issues 16:23 < sipa> you need to register for an mac developer account, i think 16:23 < jtimon> I see, thanks again 16:29 -!- aguycalled [~alex@37.120.37.13] has quit [Remote host closed the connection] 16:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:30 -!- aguycalled [~aguycalle@37.120.37.13] has joined #bitcoin-core-dev 16:34 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has joined #bitcoin-core-dev 16:34 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has quit [Changing host] 16:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:34 -!- aguycalled [~aguycalle@37.120.37.13] has quit [Ping timeout: 240 seconds] 16:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 16:49 -!- echonaut2 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 16:50 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 16:50 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds] 16:54 < michagogo> Yep 16:54 < michagogo> You need to log into developer.apple.com 16:54 < michagogo> (You don't need the $99 membership, a free account is enough) 16:55 < michagogo> Then you need to download Xcode, and pull out the SDK directory from within that 16:55 < michagogo> Unfortunately that can only be done (as of the last I heard) on a Mac 16:57 < luke-jr> michagogo: I posted some doc to the git repo with non-Mac instructions IIRC 16:58 < michagogo> Oh, really? 16:58 * michagogo looks 16:58 < sipa> luke-jr: is it included in the bitcoin repo? 16:58 < sipa> +core 16:59 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 16:59 < luke-jr> https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md 16:59 < luke-jr> sipa: yes ^ 16:59 < luke-jr> "Alternatively, you can use 7zip and SleuthKit to extract the files one by one. The script contrib/macdeploy/extract-osx-sdk.sh automates this. First ensure the dmg file is in the current directory, and then run the script. You may wish to delete the intermediate 5.hfs file and MacOSX10.11.sdk (the directory) when you've confirmed the extraction succeeded." … 16:59 < michagogo> Ah, yes 17:00 < michagogo> https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/extract-osx-sdk.sh 17:00 < michagogo> Nice! 17:01 < michagogo> August? 17:01 < sipa> luke-jr: ok, thanks 17:01 < michagogo> Wow, I've been out of the loop for a long time. 17:01 < sipa> luke-jr: i remember you finding this, but i wasn't aware it actually got pred 17:04 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 17:08 < bitcoin-git> [bitcoin] luke-jr opened pull request #9642: [Hardfork] Safe block size limit (master...bip-blksize) https://github.com/bitcoin/bitcoin/pull/9642 17:38 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 17:39 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 17:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pthfffpstjrpgirb] has quit [Quit: Connection closed for inactivity] 18:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 19:05 -!- buddhaghosa [chatzilla@gateway/vpn/mullvad/x-mnixuxrcomrvqeto] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.0/20170124094647]] 19:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 20:02 -!- kyletorpey [47b0e374@gateway/web/freenode/ip.71.176.227.116] has joined #bitcoin-core-dev 20:02 -!- chris200_ [~chris2000@p5082A1BF.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:05 -!- chris2000 [~chris2000@p5082AF6A.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 20:21 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .] 20:34 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:7544:1851:318a:8188] has joined #bitcoin-core-dev 20:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 20:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 20:44 -!- shesek [~shesek@bzq-84-110-235-21.red.bezeqint.net] has quit [Ping timeout: 245 seconds] 20:59 -!- chris2000 [~chris2000@p5DCB56DD.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 21:00 -!- dermoth [~thomas@dsl-199-102-159-125.mtl.aei.ca] has quit [Read error: Connection reset by peer] 21:01 -!- dermoth [~thomas@dsl-199-102-159-125.mtl.aei.ca] has joined #bitcoin-core-dev 21:02 -!- chris200_ [~chris2000@p5082A1BF.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 21:39 -!- neha___ [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 240 seconds] 21:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:40 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds] 21:43 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 21:43 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 21:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 21:44 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev 21:52 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 252 seconds] 21:53 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 21:55 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 21:56 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 21:56 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 21:56 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 22:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 245 seconds] 22:19 -!- Saucery [Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has joined #bitcoin-core-dev 22:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 22:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 22:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dyqixokchpoglkui] has joined #bitcoin-core-dev 23:00 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 23:02 -!- kyletorpey [47b0e374@gateway/web/freenode/ip.71.176.227.116] has quit [Ping timeout: 260 seconds] 23:20 -!- aguycalled [~aguycalle@2001:638:812:c00:2451:cbc:f54:63b6] has joined #bitcoin-core-dev 23:26 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 23:26 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds] 23:26 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 23:27 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 23:28 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:28 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:28 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Changing host] 23:28 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 23:28 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:32 -!- testtesttest [58cf2c0f@gateway/web/freenode/ip.88.207.44.15] has quit [Ping timeout: 260 seconds] 23:39 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 23:40 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:54 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]