--- Day changed Thu Apr 28 2016
00:01 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
00:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:52 -!- Amnez777 [~Amnez777@37.157.216.133] has quit [Ping timeout: 246 seconds]
00:57 -!- Hmmmm [~hmmmm@air.temetra.com] has joined #bitcoin-core-dev
01:04 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
01:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:13 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 268 seconds]
01:22 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]
01:22 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
01:23 -!- Hmmmm [~hmmmm@air.temetra.com] has quit [Quit: Leaving]
01:25 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
01:25 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
01:52 < GitHub149> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/08b37c5e06bf...06162f19d7dd
01:52 < GitHub149> bitcoin/master 67969af Wladimir J. van der Laan: build: Enable C++11 build, require C++11 compiler...
01:52 < GitHub149> bitcoin/master a398549 Cory Fields: depends: use c++11
01:52 < GitHub149> bitcoin/master 2aacc72 Wladimir J. van der Laan: build: update ax_cxx_compile_stdcxx to serial 4
01:53 < GitHub116> [bitcoin] laanwj closed pull request #7165: build: Enable C++11 in build, require C++11 compiler (master...2015_12_c++11) https://github.com/bitcoin/bitcoin/pull/7165
01:53 < gmaxwell> hurray
01:58 < wumpus> yeahhh finally
02:11 < sipa> \o/
02:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:12 < wumpus> jonasschnelli: FYI (reading your post in #7917) debug.logs compress *very* well
02:12 < jonasschnelli> Right. Was to lazy.
02:12 < wumpus> heh
02:12 < jonasschnelli> At least i should enable mod_deflate
02:12 < jonasschnelli> (for apache)
02:14 < wumpus> right, that'd at least save bandwidth
02:15 < jonasschnelli> Post #7165 means we can use C++11 features now? Right? Core will no longer compile on non C++11 compilers?
02:16 < gmaxwell> I belive the goal was to avoid refactoring to use c++11 but to mostly use it in new code, so that things that we have to backport won't need to be rewritten, and so weren't not causing gratitious churn right now.
02:16 < sipa> i wonder how much performance we gained :)
02:17 < jonasschnelli> Hmm... is there no plan for removing the boost beast longterm?
02:17 < gmaxwell> Absolutely, but not now.
02:17 < wumpus> yes, we can use C++11 features now
02:18 < jonasschnelli> So, new code will use c++11 foreachs old code still sticks with BOOST_FOREACH?
02:18 < wumpus> and yes I'd suggest mostly doing so in the anicillary parts, not in main.cpp and other things that should be backported to 0.12 for segwit
02:18 < gmaxwell> I think we shouldn't do any major refactors to use C++11 things until we're no longer supporting a non-C++11 release. (on top of the orindary desire to not have a lot of refactor disruption)
02:18 < wumpus> using it in things that are new features in 0.13 anyhow is fine
02:18 < sipa> i think converting sync.h to use std::thread would be fine, for example
02:18 < jonasschnelli> gmaxwell: good point!
02:18 < sipa> as it is very unlikely to conflict with anything
02:18 < sipa> but yes, don't go all over the code to convert everything
02:19 < wumpus> sipa: definitely, that is very unlikely to have to be changed for segwit, or anything backported
02:19 < gmaxwell> self contained things... yep, new features. yep. 
02:19 < wumpus> so for the utilities and such: fine
02:19 < jonasschnelli> Okay. Are there any c++11 features we should avoid? Like atomics?
02:20 < wumpus> after segwit is merged to 0.12 I don't care anymore and IMO we can go full c++11 crazy
02:20 < wumpus> (keeping in mind the risks that refactors always bring, of course)
02:20 < jonasschnelli> Right. I agree with gmaxwell: As long as we support 0.12 (non C++11) we should not refactor to much
02:21 < wumpus> I've arbitrarily set the minimum to gcc 4.7 and clang 3.3 in release-notes, don't know if they have atomics, it's open for discussion anyhow
02:21 < gmaxwell> atomics aren't a replacement for proper locking... I don't know that we'd have that much use for atomics, but I am not aware of a reason to bar them right now.
02:21 < sipa> https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
02:21 < sipa> 4.7 has atomics
02:22 < wumpus> nice
02:22 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:22 < gmaxwell> (like, for example, they might get used in the RNG.. but most places should just use conventional locking)
02:23 < wumpus> right, definitely use convential locking unless there is a specific performance bottleneck where atomics wuld help a lot
02:23 < gmaxwell> (because most of the time you need more complex data structures than atomics provide, and constructing safe data structures out of atomics is a bit rocket sciency for 99.999% of code)
02:23  * sipa wants: auto, range for, rvalue references/moves, std::thread etc, nullptr, override, initializer lists
02:23 < wumpus> code using atomics is usually even harder to review
02:23 < gmaxwell> priorities should be changes that improve code safty, and changes that eliminate dependency on boost.
02:23 < gmaxwell> once refactoring changes start.
02:23 < wumpus> (unless it is for really trivial things like counters ...)
02:24 < gmaxwell> wumpus: even with counters, you seldom have just one counter... :)
02:24 < wumpus> right
02:24 < sipa> for example for the debug=bench counters, atomics could be used i think?
02:25 -!- Amnez777 [~Amnez777@37.157.216.133] has joined #bitcoin-core-dev
02:25 < sipa> all you need is += and get
02:25 < gmaxwell> so long as you don't care if a print isn't mixing up data from seperate runs... for benchmarking its probably okay...
02:25 < sipa> yeah
02:26 < sipa> then again, they are currently just under cs_main and there is no reason to change that, as all the surrounding code also needs cs_main for now
02:26 < wumpus> the debug=bench counters/accumulators are all used one at a time anyway afaik
02:26 < gmaxwell> I've seen 'lock free' network stats code cause stupid failures in production systems, e.g. where there was a numerator and denominator, each updated atomically... and code that divided them and crashed with divide by zero because updating them indivigually atomically wasn't enough.
02:28 < jonasschnelli> Call for a quick review: https://github.com/bitcoin/bitcoin/pull/7826 (<-- this will allow to GUI to display RBF conflicts)
02:30 < gmaxwell> sipa: also when performance matters, cacheline bouncing is _really_ expensive.  atomics may not be a big performance win vs an ordinary lock... to get better performance: use per thread accumulators and infrequently merge them...
02:31 < wumpus> jonasschnelli: it's a step forward - I do agree with marcofalke that what we really want here is a way to bring attention to the highest seq# transaction and 'grey out' the replaced ones. I'm not sure using the conflicts cross is the best way for that, it maybe looks to intimidating.
02:32 < wumpus> (e.g. as if something is really wrong)
02:32 < wumpus> but in any case your pull is a clear step forward 
02:33 < sipa> gmaxwell: aware (look at the crc code that you're running for me :p)
02:33 < wumpus> better than showing both in the same way as waiting to be confirmed
02:33 < wumpus> crc code?
02:33 < jonasschnelli> wumpus: Right. I guess only RBF can result in a mempool conflict. So using a other icon should be fine.
02:33 < jonasschnelli> Let me overhaul it.
02:33 < sipa> wumpus: i'm benchmarking some crcs for a base32 address format :)
02:34 < wumpus> sipa: have you seen https://github.com/laanwj/crcbench? (have been playing with crc instructions on aarch64 and sse42, and gmaxwell benchmarked on a few systems as well)
02:34 < JackH> I know this is not the place for it, but could one of you help me out for a bitcoin-cli command I am struggling about? :)
02:34 < wumpus> that's all for crc32c though as that's the one in leveldb
02:35 < jonasschnelli> JackH: you are writing a new command (dev) or using a existing one (non-dev)?
02:36 < sipa> wumpus: benchmarking how well they detect errors, not performance
02:36 < wumpus> ohh okay
02:36 < sipa> wumpus: https://github.com/sipa/ezbase32
02:37 < JackH> what I want to do is to ./bitcoin-cli sendfrom but also include a fee. And I cant find any documentation on how to include both "sendfrom" and " settxfee ". The wiki doesnt explain it, and I am confused if I can type both commands on the same line? 
02:37 < sipa> JackH: settxfee modifies a global setting
02:37 < wumpus> do the settxfee before the sendfrom
02:37 < sipa> JackH: you need to run them separately
02:37 < sipa> also, sendfrom will by default include a fee, based on estimations
02:37 < JackH> ahh it modifies the global. So should I instead edit the .conf file and then do the sendfrom?
02:38 < sipa> wumpus: latest development is a BCH code over GF(2^32) that guarantees detecting 4 errors with 6 base32 checksum
02:38 < sipa> eh over GF(2^5)
02:38  * jonasschnelli thinks we should probably add a optional feerate parameter to fundrawtransaction
02:38 < wumpus> jonasschnelli: there isn't one yet?
02:38  * jonasschnelli looking..
02:38 < wumpus> I'm surprised, would be so much better than changing a global
02:39 < jonasschnelli> no.. i don't think so. Maybe there is a PR.
02:39 < sipa> there is a pr
02:39 < jonasschnelli> Hard to keep track of everything. :)
02:39 < wumpus> no, the PR does it wrong
02:39 < jonasschnelli> It was an absolute fee IIRC
02:39 < jonasschnelli> you pass in a feerate that one could determine with estimatefee
02:40 < wumpus> ... which everyone is trying to convince the author of that it's a bad idea, but he won't reconsider, probably going to close it soon
02:40 < jonasschnelli> The ugly thing is, that CreateTransaction uses the static DEFAULT_TARGET
02:40 < wumpus> passing in an optional feerate would be the obvious thing to do
02:40 < jonasschnelli> So, this would require some refactoring.
02:40 < sipa> just add a confirmation target to coincontrol
02:41 < jonasschnelli> Yes. This sounds good.
02:41 < wumpus> right, just slap it into coincontrol
02:41 < sipa> wasn't there a PR that added a bunch of options to fundrawtransaction?
02:41 < sipa> including that
02:41 < jonasschnelli> Not the feerate.
02:41 < jonasschnelli> But the rest is merged.
02:41 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
02:41 < jonasschnelli> Which finally allows me to write my iOS Core Wallet client
02:41 < wumpus> we have a bunch of options in fundrawtransactions, which is why I was confused
02:42 < wumpus> yes that one was merged
02:42 < jonasschnelli> (keep keys on smartphone, use watchonly core wallet, use fundrawtransactin, sign on the smartphone)
02:42 < wumpus> jonasschnelli: nice
02:42 < wumpus> sipa: how does that compare to standard CRC32?
02:42 < jonasschnelli> It really made me thing that the wallet (in watchonly mode) is just a utility to keep track of user-(group-)relevant transactions.
02:43 < jonasschnelli> like a selective tx-/address-index
02:43 < wumpus> jonasschnelli: it is
02:43 < wumpus> joinmarket uses it the same way
02:43 < sipa> wumpus: a CRC32 isn't compatible with base32 (as it would produce 6.4 characters)
02:44 < sipa> wumpus: i'm including a CRC30 though, and it seems to perform way better than the theory would predict
02:46 < wumpus> sipa: ah right, get it now, output needs to be a multiple of 5 bits, not 32 bit
02:47 < sipa> right, it's a checksum on base32 elements, so it takes a series of base32 tokens, and produces 6 extra ones
02:47 < wumpus> instead of doing the checksum before the encoding, you do it afterward on the encoding itself
02:48 < wumpus> I suppose that does make it easier to reason about the properties, yes
02:48 < wumpus> and it's also slightly more convenient, no need to decode to check
03:06 < sipa> indeed, though decoding base32 is sufficiently simple that it does not really matter
03:07 < wumpus> yes it's not so unfortunate as base58
03:16 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit []
03:22 < GitHub185> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/06162f19d7dd...574ddc63d6ff
03:22 < GitHub185> bitcoin/master 17a6a21 Wladimir J. van der Laan: qt: Make it possible to show details for multiple transactions...
03:22 < GitHub185> bitcoin/master f135e3c Wladimir J. van der Laan: qt: Add transaction hash to details window title
03:22 < GitHub185> bitcoin/master 574ddc6 Wladimir J. van der Laan: Merge #7939: qt: Make it possible to show details for multiple transactions...
03:22 < GitHub134> [bitcoin] laanwj closed pull request #7939: qt: Make it possible to show details for multiple transactions (master...2016_04_qt_multiple_transaction_details) https://github.com/bitcoin/bitcoin/pull/7939
03:23 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 252 seconds]
03:23 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
03:26 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
03:26 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
03:35 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Quit: Page closed]
03:56 < GitHub110> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/574ddc63d6ff...d9594bfe0c3e
03:56 < GitHub110> bitcoin/master 8aa7226 jmacwhyte: Fix IsInitialBlockDownload to play nice with testnet
03:56 < GitHub110> bitcoin/master d9594bf Wladimir J. van der Laan: Merge #7514: Fix IsInitialBlockDownload for testnet...
03:56 < GitHub167> [bitcoin] laanwj closed pull request #7514: Fix IsInitialBlockDownload for testnet (master...fixisinitialblock) https://github.com/bitcoin/bitcoin/pull/7514
04:32 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 250 seconds]
04:35 < wumpus> re: c++11 refactoring, we should convert the auto_ptrs to unique_ptrs IMO
04:37 < sipa> i'm seeing the very strange error "Insufficient funds" in listtransactions.py (segwit branch, but nothing should have changed there)
04:37 < sipa> but only when i run it through rpc-tests
04:37 < sipa> if i run it standalone it works
04:37 < sipa> is there any difference in setup between them?
04:37 < wumpus> try deleting all cache directories
04:39 < wumpus> otherwise, no, there is no difference in setup, rpc-tests simply starts the individual tests as processes
04:40 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:45 < GitHub41> [bitcoin] laanwj opened pull request #7964: Minor changes for c++11 consistency (master...2016_04_c++11_consistency) https://github.com/bitcoin/bitcoin/pull/7964
04:45 -!- NotAnNSAgent [~NotAnNSAg@46.166.190.137] has joined #bitcoin-core-dev
04:48 -!- dermoth_ [~thomas@dsl-216-221-56-137.mtl.aei.ca] has joined #bitcoin-core-dev
04:52 -!- dermoth [~thomas@dsl-66-36-157-105.mtl.aei.ca] has quit [Ping timeout: 260 seconds]
04:53 < GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9594bfe0c3e...a9c8b744e887
04:53 < GitHub168> bitcoin/master 61c0170 Pavel Janík: Log invalid block hash to make debugging easier.
04:53 < GitHub168> bitcoin/master a9c8b74 Wladimir J. van der Laan: Merge #7952: Log invalid block hash to make debugging easier....
04:53 < GitHub128> [bitcoin] laanwj closed pull request #7952: Log invalid block hash to make debugging easier. (master...20160426_Log_invalid_block) https://github.com/bitcoin/bitcoin/pull/7952
05:09 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
05:10 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
05:13 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
05:32 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
05:36 < GitHub95> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a9c8b744e887...5725807402ec
05:36 < GitHub95> bitcoin/master 9c0bcb6 instagibbs: push back getaddednodeinfo dead value
05:36 < GitHub95> bitcoin/master 5725807 Wladimir J. van der Laan: Merge #7926: [RPC] push back getaddednodeinfo dead value...
05:36 < GitHub86> [bitcoin] laanwj closed pull request #7926: [RPC] push back getaddednodeinfo dead value (master...getaddedpushbackmaster) https://github.com/bitcoin/bitcoin/pull/7926
05:48 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 276 seconds]
05:49 -!- jtimon [~quassel@79.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:53 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
06:11 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:15 -!- Amnez777 [~Amnez777@37.157.216.133] has quit [Ping timeout: 252 seconds]
06:17 -!- Amnez777 [~Amnez777@37.157.216.133] has joined #bitcoin-core-dev
06:32 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
06:34 < GitHub81> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5725807402ec...20f9ecd343bb
06:34 < GitHub81> bitcoin/master c7aac2d 21E14: Deprecating the remaining LogPrintf dependencies that were made obsolete in PR #7459.
06:34 < GitHub81> bitcoin/master 20f9ecd Wladimir J. van der Laan: Merge #7962: CalculateNextWorkRequired Cleanup...
06:34 < GitHub69> [bitcoin] laanwj closed pull request #7962: CalculateNextWorkRequired Cleanup (master...cleanpow) https://github.com/bitcoin/bitcoin/pull/7962
06:41 -!- jtimon_ [~quassel@79.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:41 -!- jtimon_ [~quassel@79.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
06:54 -!- shesek [~shesek@bzq-84-110-109-203.red.bezeqint.net] has quit [Read error: Connection reset by peer]
06:57 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:59 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:01 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]
07:16 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:22 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
07:22 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:30 -!- cryptapus_ is now known as cryptapus
07:46 -!- shesek [~shesek@bzq-84-110-110-201.cablep.bezeqint.net] has joined #bitcoin-core-dev
08:03 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
08:19 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
08:20 -!- Guyver2_ is now known as Guyver2
08:23 < Chris_Stewart_5> "BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age," 
08:23 < Chris_Stewart_5> Shouldn't 'input' be changed to 'output'?
08:24 < Chris_Stewart_5> this is in BIP112
08:40 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
08:46 < kanzure> for syncing an external application against bitcoind block history, i think getblock and _batch requests of getblockhash are the only options when receiving a blocknotify event, right?
08:46 < kanzure> i was thinking about implementing a getallblockhashes rpc command. i'm hesitant though because i'm not sure why it doesn't already exist.
08:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
08:50 < kanzure> the only other way to check if you are missing gaps of block history is by recursively calling getblockhash and getblock (starting from your last known best block) and ignoring the blocknotify parameter value. however, this is problematic for developers because they would have to also implement a "reverse" mode because if you run "getblock" from your last known block in some database then you will also have to go back in history in ...
08:50 < kanzure> ... the event of a recent reorg (e.g. maybe you had a stale block at your tip). this seems like more work than just working with a list of all blockhashes and comparing against your list of known blockhashes. right?
08:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:52 < kanzure> alternatively: how much overhead is _batch rpc stuff in comparison to a single rpc call like a hypothetical "getallblockhashes"?
08:55 < wumpus> pretty much the same
08:56 < wumpus> the RPC batching functionality is severly underused, an example is contrib/linearize
08:56 < instagibbs> wumpus, so, how do I use it
08:56 < wumpus> it requests all the block hashes, though not in a way that copes with reorgs 
08:57 < wumpus> (it's meant as one-shot)
08:57 < kanzure> https://github.com/bitcoin/bitcoin/blob/7fc25c2e5d493f4ef46c9b5831d92886bcea17a8/contrib/linearize/linearize-hashes.py#L64
08:57 < kanzure> oh this is using an interval
08:57 < kanzure> alright well, my method copes with reorgs by grabbing all blockhashes
08:58 < sipa> https://github.com/sipa/bitcoin-stats/blob/master/keepdump.pl
08:58 < sipa> that maintains a list of all blocks in a text file
08:58 < kanzure> _batch 500,000 rpc requests for getblockhash is taking me like >10 seconds. wouldn't a hypothetical "getallblockhashes" take less than this? do we have an index in leveldb of all the blockhashes?
08:58 < sipa> it also doesn't deal with reorgs, as it just puts all blocks there
08:58 < sipa> kanzure: nope, in memory
08:58 < sipa> :p
08:58 < kanzure> in memory sounds good, that should be fast to dump over rpc
08:59 < kanzure> yeah we should do this
08:59 < sipa> sounds like something for the REST interface
08:59 < sipa> actually, doesn't it already have that?
08:59 < sipa> fetching a range of block headers
08:59 < kanzure> range is incompatible with reorgs
09:00 < kanzure> you can do range + confirmationwaitdepth i guess (where confirmationwaitdepth is your risk threshold for accepting deposits or payments or whatever)
09:00 < wumpus> kanzure: until http streaming is implemented we don't really want anything that returns that much data
09:01 < kanzure> wumpus: well, that makes sense, but in the mean time i'm not sure what applications are using...? calling getblock a few hundred thousand times is dumb.
09:01 < wumpus> in the meantime just use batching
09:01 < kanzure> but... it's slow.
09:01 < sipa> kanzure: you only need to call it a few 100000 times at first startup
09:01 < wumpus> REST is much faster than using getblock
09:02 < sipa> kanzure: after that you just look at the tip, and go backwards to update your best known state
09:02 < wumpus> saves the encoding overhead as first hex then JSON
09:02 < kanzure> getblock isn't the problem, i'm using _batch with getblockhash only
09:02 < wumpus> and you can pipeline requests on the same TCP connection
09:02 < wumpus> also how many times do you expect to do this? is ten seconds really a problem?
09:02 < kanzure> sipa: "go backwards" using getblock? i am "going backwards" using _batch getblockhash because i don't want to call "getblock" a few thousand times.
09:03 < kanzure> wumpus: well i am getting socket timeouts... so yes. usually it does not take that long. but it varies. sometimes i am getting socket timeouts.
09:03 < sipa> kanzure: i don't understand why you need to see all hashes
09:03 < wumpus> increase your socket timeout
09:03 < wumpus> it's the client that timeouts, never the server
09:03 < wumpus> server won't timeout while it's working and not waiting for client input
09:03 < kanzure> sipa: i don't need to see all the hashes, i agreed with you that a range is OK (like in the linearize script) plus/minus the number of confirmations that you feel safe waiting for, e.g. so that you can be reorg-compatible.
09:03 < sipa> kanzure: no, that is not what i mean
09:04 < sipa> kanzure: i mean you keep a list of hashes in your application; at block notify, you call getblockhash backward from the tip until you hit a hash you've already seen
09:04 < kanzure> wumpus: correct. it's definitely the client that is timing out.
09:04 < wumpus> FYI my attempt at http streaming (still kind of unstable) https://github.com/bitcoin/bitcoin/pull/7759
09:04 < wumpus> kanzure: the default timeout is set to 30 seconds or so, that's not a lot, esp if you're batching
09:05 < wumpus> instagibbs: linearize provides an example, I should also have a very simple proof of concept somewhere but can't find it  right now
09:05 < kanzure> sipa: i guess i could limit the getblockhash calls in my _batch request, to be (blockheight in database) minus (200 confirmations) or something.
09:05 < kanzure> wumpus: is that server or client socket timeout default?
09:05 < sipa> kanzure: i think using batching is overkill; just go one by one
09:05 < kanzure> sipa: that takes a lot longer.
09:06 < sipa> in almost all cases you just need 1 call!
09:06 < wumpus> kanzure: I don't know, check for yourself
09:06 < wumpus> (it depends on what client library you use)
09:06 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
09:07 < kanzure> sipa: hmm okay. right.
09:07 < wumpus> with python authserviceproxy you can simply specify it in the constructor
09:07 < wumpus> instagibbs: https://gist.github.com/laanwj/f2e0238bd151d5365c07bdd03467588b
09:09 < kanzure> wumpus: sipa: thank you.
09:22 -!- BCBot [~BCBot@213.200.193.129] has joined #bitcoin-core-dev
09:24 -!- cdecker [513e9e6e@gateway/web/freenode/ip.81.62.158.110] has joined #bitcoin-core-dev
09:25 -!- cdecker [513e9e6e@gateway/web/freenode/ip.81.62.158.110] has quit [Client Quit]
09:26 < instagibbs> cool thanks
09:34 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:40 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
09:41 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
09:42 -!- BCBot [~BCBot@213.200.193.129] has quit [Remote host closed the connection]
09:43 -!- BCBot [~BCBot@213.200.193.129] has joined #bitcoin-core-dev
09:57 -!- earlest [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
10:00 -!- bysherper [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
10:02 -!- bysherper [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
10:04 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
10:05 -!- earlest [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
10:08 < GitHub114> [bitcoin] laanwj opened pull request #7966: http: Do a pending c++11 simplification handling work items (master...2016_04_httpserver_c++11) https://github.com/bitcoin/bitcoin/pull/7966
10:27 -!- wallet421 [~wallet42@200.68.136.182] has joined #bitcoin-core-dev
10:32 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 250 seconds]
10:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
10:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:45 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
10:48 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
11:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
11:05 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:14 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
11:18 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
11:22 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
11:27 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
11:29 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:35 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
11:36 -!- bysherper [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
11:37 -!- wallet421 [~wallet42@200.68.136.182] has quit [Quit: Leaving.]
11:40 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 268 seconds]
11:50 -!- Guest45728 [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev
11:51 < jonasschnelli> why does CFeeRate has not setter?
11:51 < jonasschnelli> Or am I missing something?
11:52 -!- Guest45728 is now known as roidster
11:56 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
11:57 < wumpus> it's just a value, if you need to assign a new value just assign a new CFeeRate(...) object
11:58 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 250 seconds]
11:58 < wumpus> no need to be able to change it partially
11:58 < jonasschnelli> Right. But overloading = op. with a CAmount would be something. Not?
11:58 < wumpus> I don't think that's necessary
11:58 < wumpus> (sounds slightly confusing to me)
11:58 < jonasschnelli> But right. feeRate = CFeeRate(new) is fine.
11:58 < wumpus> better to be explicit
11:59 < gmaxwell> Meeting time soon.
12:00 < jonasschnelli> jtimon: meeting now.
12:00 < jtimon> thanks
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Apr 28 19:00:11 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < gmaxwell> sipa: jonasschnelli wumpus morcos sdaftuar kanzure BlueMatt jtimon cfields luke-jr petertodd 
12:00 < wumpus> proposed topics?
12:00 < sipa> mildly present
12:01 < kanzure> i propose follow-up from last week re: segwit code review, and new/upcoming tasks on that front
12:01 < morcos> i'm here for 10 mins
12:01 < kanzure> gmaxwell: thanks for the ping
12:01 < jonasschnelli> I have two very small topic proposals: wording for RBF, a request for creating/storing CI material
12:01 < gmaxwell> morcos: anything you want to talk about in 10 minutes.
12:01 < cfields> thanks, here
12:01 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has joined #bitcoin-core-dev
12:01 < morcos> just to encourage anyone who is going to review segwit to get on it!  :)  
12:02 < wumpus> action items of last time were a) more code review of segwit 2) kanzure: look at test coverage output 3) (Luke) update GBT segwit stuff 4) (jtimon) tutorial to enable travis on your own repo 5) (cfields) travis changes requiring some downtime 6) merge #7920 when cfields says so
12:02 < kanzure> i have some segwit review notes but they are not precisely publicly consumable, can i get a volunteer to go through my notes? ideally not sipa :)
12:02 < gmaxwell> What is the status of the segwit BIPs? are they all consistent with the implementation right now?
12:02 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
12:02 < kanzure> wumpus: if i was supposed to look at test coverage output then i totally barfed on that, my bad-- i thought someone else took that.
12:02 < wumpus> last two items are done at least, transition to trusty and c++11 was succesful
12:03 < gmaxwell> \O/
12:03 < wumpus> kanzure: yes the name is who suggested it, Idon't know the context 
12:03 < jtimon> wumpus: re 4 I thought cfields was going to write the tutorail, not me...I'm still on https://docs.travis-ci.com/user/getting-started/ 
12:03 < sdaftuar> kanzure: i'd be happy to review your notes
12:03 < kanzure> sdaftuar: cool, i will spam you with them
12:03 < cfields> jtimon: sorry, i got lost in the transition stuff
12:03 < wumpus> jtimon: oh maybe he's going to, but he had a lot on his hands
12:04 < jtimon> no hurry, just saying that I'm not working on that
12:04 < wumpus> okay :)
12:04 < wumpus> how is the review of segwit going?
12:04 < kanzure> sdaftuar: you have been spammed, thanks.
12:06 < morcos> wumpus: i'm feeling pretty good, but it's hard to tell who all has done deep commit by commit reviews
12:06 < kanzure> topic suggestion-- how to convince sipa to give more context about testing status of segwit
12:06 < sdaftuar> wumpus: i'm slowly making my way through
12:06 < wumpus> morcos: good to hear that you're making your way through 
12:06 < kanzure> morcos: perhaps we should all post about our review status?
12:06 < cfields> tangentially: I've finally started working with the mining pools (with Kang's help translating) to ensure that their real-world environments. Aim is to get at least one segnet block mined by each pool. Happy to report that last night, BTCC's patched pool mined a few blocks. I'll be working with the others in the coming days
12:07 < morcos> cfields: oh thats great!
12:07 < cfields> *segnet block with witness txs, ofc
12:07 < kanzure> i have done a preliminary read of all the diffs for segwit but not commit-by-commit.... i have a number of places that i am considering investigating the test situation more closely but it's all probably dead-ends ( sdaftuar to advise ).
12:07 < morcos> time for someone else to get some segnet coins, i have too many
12:08 < sipa> i could list a few areas where i think mildly tricky things are done that warrant review
12:08 < kanzure> yes please.
12:09 < wumpus> #action (sipa) list a few areas where i think mildly tricky things are done that warrant review
12:09 < morcos> sipa: in particular the areas that are new for me (such as the wallet/signing code) are harder to be confident about.  i'd feel better knowing others are reviewing it as well
12:09 < sipa> good to know
12:09 < kanzure> signaturehash changes were specified by bip and one (trivial) review task is "confirm it follows the bip spec"
12:10 < morcos> sipa: harder b/c of me, not b/c the code is tricky looking
12:10 < instagibbs> morcos, maybe have people express review coverage with amount of certainty based on familiarity with the code
12:10 < sipa> the wallet signing code adds a refactor to stop working directly on scriotsigs, but initially work on just the stacks being pushed, and only convert them at the last step
12:11 < instagibbs> for me, review of wallet code was much easier than parsing the tree commitment stuff
12:11 < cfields> kanzure: some input from other projects (NicolasDorier *poke*) may be helpful there. 
12:11 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev
12:11 < morcos> instagibbs: i like that idea. not sure how easy it is to break up
12:11 < instagibbs> that said, I read *every* commit, and attempted best-effort understanding
12:11 < sipa> cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
12:12 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
12:12 < morcos> ok got to run.  overall, yay for c++11, yay for segwit!
12:12 < cfields> sipa: ah, right. ack.
12:12 -!- NotAnNSAgent [~NotAnNSAg@46.166.190.137] has quit [Remote host closed the connection]
12:12 -!- NotAnNSAgent [~NotAnNSAg@46.166.137.212] has joined #bitcoin-core-dev
12:12 < gmaxwell> I was talking to nickler about doing consensus harness tests for verifying consensus consistence, e.g. between 0.13 and 0.12.x or pre-segwit. Maybe there will be something to report there in a week or so.
12:12 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
12:13 < jtimon> yeah, for example, I'm less familiar with the p2p and wallet parts, unfortunately I don't think I will be able to give a full utACK to #7910, but that of course shouldn't not stop it from being merged
12:13 < instagibbs> jtimon, which brings me to my point, aside from sipa and a few others, I doubt anyone can full utACK #7910
12:14 < kanzure> one of the things i'd like to investigate more closely is the set of tests that were written versus the expected set of tests... but hard to find all the corner cases.
12:14 -!- wallet421 [~wallet42@200.68.136.182] has joined #bitcoin-core-dev
12:15 < jtimon> instagibbs: good point, the PR touches many parts. I think I will focus on the consensus and relay policy parts and only utACK that
12:15 < sipa> also in general: what do people think of the strategy i've been following to not rebase/squash, but only add small patches and a changing merge commit at the end?
12:15 < kanzure> sipa: i think that is a good idea. it gives us time to ACK various older commits.
12:15 < instagibbs> jtimon, seems wise, people have to self-select what they feel competent to review
12:15 -!- wallet421 [~wallet42@200.68.136.182] has quit [Client Quit]
12:16 < sipa> at some point i'll squash and rebase in such a way that the resulting tree id identical to the old broken down branch
12:16 < jtimon> sipa: no strong opinion but it seems to partly defeat the point of having the commits separated in related sections (btw, I would separate p2p from consensus)
12:17 < kanzure> tree id similarity is a nice approach....
12:17 < kanzure> (git ls-tree and such)
12:17 < sipa> jtimon: i'll keep the section
12:17 < sdaftuar> sipa: some kind of warning before you squash/rebase would be helpful for me at least
12:18 < sdaftuar> sipa: but i like how you've done it so far
12:18 < kanzure> it would also be good if you could keep the original commits around on your git repo
12:18 < sipa> kanzure: of course
12:18 < jtimon> sipa: I see, so your question is more about squashing only once at the end, fine with me
12:18 < sipa> it needs to be verifiable
12:18 < kanzure> good, thanks.
12:18 < cfields> sipa: you can just push to a spare branch before final squash, then we can diff the two
12:19 < jonasschnelli> only add commits, once we have enough ACKS, hash the diff, rebase, check the hash of the diff and merge?
12:19 < sipa> jonasschnelli: indeed
12:20 < wumpus> ok next topic?
12:20 < wumpus> #topic status of the segwit BIPs
12:21 < wumpus> (gmaxwell)
12:21 < achow101> bip 144 needs to include the service bit stuff
12:22 < wumpus> everyone agree?
12:23 < sipa> ugh, that was never uodated
12:23 < sipa> yes, agree
12:23 < wumpus> #action bip 144 needs to include the service bit stuff
12:23 < gmaxwell> I suppose we should try to extract some feedback e.g. from roastbeef to reimplemented, who might be aware of other limitations in the spec.
12:24 < instagibbs> roasbeef*
12:24 < petertodd> just noticed someone has a python-bitcoinlib segwit branch too
12:24 < achow101> armory does as well
12:24 < petertodd> (sorry, just got in)
12:25 -!- matsjj [~matsjj@p20030089EA01982D45BF0BFE567F0750.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:25 < wumpus> petertodd: just in time for the python-bitcoinlib segwit branch!
12:25 < petertodd> wumpus: ha yeah - no credit to me though :)
12:26 < wumpus> #action (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
12:27 < sipa> we have gotten some comments from a few people and making small clarifications frequently
12:27 < sipa> including from tadge
12:27 < sipa> i'm surprised nobody commented about the service bit
12:28 < achow101> sipa: I think I brought it up a couple of weeks ago but didn't follow up on it
12:28 < sipa> achow101: sorry then!
12:29 < instagibbs> I can verify 141 and 143 match up
12:30 < wumpus> great
12:31 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
12:31 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
12:32 < sipa> small update: the reviewer that btcdrak contacted about ctaes wrote a report
12:32 < jonasschnelli> sipa: the tor lead dev?
12:33 < sipa> jonasschnelli: no, someone mathhew green recommemded
12:33 < sipa> he formally proved that some parts were correct, and analyzed the condtant timeness
12:33 < jonasschnelli> Okay. Good. What was the result?
12:33 < sipa> i can share the reoort
12:33 < petertodd> sipa: +1
12:33 < sipa> a+ :)
12:33 < jonasschnelli> sipa: Can you add it on your ctaes repository?
12:33 < wumpus> awesome!
12:34 < cfields> sipa: nice!
12:34 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 250 seconds]
12:35 < sipa> any more topics? i'll be off otherwise
12:35 < jonasschnelli> RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
12:36 < petertodd> jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
12:36 < jl2012> bringing segwit testing to testnet?
12:36 < gmaxwell> the former, I think. It's incorrect to say non-RBF is non-replacable; they're just somewhat less replacable. 
12:37 < wumpus> agree with gmaxwell
12:37 < jonasschnelli> Okay. I agree as well. Will continue with this term.
12:37 < instagibbs> 'mempool-replaceable' ?
12:37 < petertodd> doublespends happen all the time, and only a small subset of them are opt-in RBF txs
12:38 < wumpus> but RBF transactions the user can easily replace themselves
12:38 < jl2012> sipa: are we ready to define the testnet BIP9 parameter for segwit?
12:38 < wumpus> that should be the focus imo
12:38 < wumpus> what the user can do with it
12:38 < jonasschnelli> instagibbs: I was also thinking about that. But does the normal bitcoin-qt user really knows what the mempool is?
12:38 < jtimon> "standard-policy-0.12-replaceable"?
12:38 < jonasschnelli> :}
12:39 < petertodd> jtimon: all the user's node knowns is they think it's replacable, so the 0.12 is implicit :)
12:39 < jonasschnelli> "standard-policy-0.12-BIP125-replaceable"
12:39 -!- chris2000 [~chris2000@customer-static-225-38.wobline-ip.de] has quit []
12:39 < wumpus> yes the 0.12 is implicit, the BIP125 part makes sense
12:39 < jtimon> yeah, 0.12 was kind of joking, the point is all tx are equally replaceable with a custom policy, the opt-in stuff is just about the standard policy
12:39 < petertodd> don't we already have a bip125-replacable or similar name used in the RPC anyway?
12:40 < jonasschnelli> petertodd: Yes. Listtransaction
12:40 < wumpus> yes entry.push_back(Pair("bip125-replaceable", rbfStatus));
12:40 < jtimon> ack bip125-replaceable
12:40 < jonasschnelli> Also I think someone should refactor the RBF BIP125 rules to the new rbf.cpp
12:40 < petertodd> jtimon: you can also replace txs by flooding mempools and getting them kicked out :)
12:41 < jonasschnelli> The bumpfee or feealter command could than re-check the validity
12:41 -!- Michail1 [~michail@michail.com] has joined #bitcoin-core-dev
12:41 < jonasschnelli> s/re-check/pre-check
12:41 < jonasschnelli> In the GUI we should probably just use the term "replaceable".
12:42 < jtimon> then we have the same problem I think
12:42 < petertodd> jonasschnelli: "easily replacable"
12:42 < jtimon> opt-in-repleaceable ?
12:42 < petertodd> jonasschnelli: or heck, "trivially replacable"
12:43 < paveljanik> "updatable"?
12:43 < luke-jr> "replacement-requested"
12:43 < jonasschnelli> of "signs replicability"?
12:43 < petertodd> paveljanik: eh, changing the name to something other than replacable would invite trolling possibly
12:44 < paveljanik> replacability signalled ;-)
12:44 < jonasschnelli> replacability signalled: +1
12:44 < wumpus> yes I think whatever the name is it should contain 'replace', otherwise it's too confusing, introducing completely new terminology
12:44 < petertodd> wumpus: +1
12:44 -!- muuqwaul [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
12:44 < jonasschnelli> Indeed
12:44 < wumpus> replaceability signalled sounds good to me
12:44 < petertodd> sure, why not
12:44 < jonasschnelli> ack
12:44 < jtimon> "replace explicitly allowed"?
12:45 < sdaftuar> fee-replaceable ?
12:45 < jonasschnelli> sdaftuar: but it could also add a output
12:45 < jtimon> I mean, "replacability signalled" is good enough for me
12:45 < jonasschnelli> sdaftuar: but right. You mean replaceable by fee
12:45 < sdaftuar> yeah, you can replace it if you up the fee
12:46 < jonasschnelli> "fee-replacability signalled"?
12:46 < petertodd> jonasschnelli: which is tricky, because any low fee tx is in practice replacable by fee regardless of whether bip125 is used or not
12:46 < sdaftuar> but not by your wallet
12:46 < wumpus> I don't think the GUI term needs to be so specific - just make sure that the mouseover or other documentation explains it in more detail
12:47 -!- gevs [~greg@ip-62-235-46-57.dial.scarlet.be] has joined #bitcoin-core-dev
12:47 -!- gevs [~greg@ip-62-235-46-57.dial.scarlet.be] has quit [Changing host]
12:47 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
12:47 < sdaftuar> +1 
12:47 < jonasschnelli> Sure. But the term would also be for attributing incoming payment.
12:47 < petertodd> oh, key question: are we going to show this for all txs, or just txs sent by the user?
12:47 < paveljanik> sdaftuar, depends on the wallet IMO
12:47 < jtimon> petertodd: exactly, for all we know, miners could replace by hash alphabetic order rather than fees
12:47 < cfields> sdaftuar: i like that, but it describes the mechanics more than the intent.
12:47 < jonasschnelli> petertodd: incoming and outdoing.
12:47 < petertodd> jonasschnelli: see, if it was just outgoing, this conversation would be a lot simpler :)
12:48 < wumpus> replacability signalled is fine, let's move on
12:48 < jonasschnelli> incoming tx: "replacability signalled", create tx: "[ ] signall replacability"
12:48 < jonasschnelli> ack.
12:48 < jtimon> what was wrong about "Opted in to replacement" or something along those lines?
12:48 < wumpus> any other topics?
12:49 < jtimon> yeah, nv, "replacability signalled" does it
12:49 < jtimon> s/nv/never mind
12:49 < jonasschnelli> topic: another boring one, not sure if this is the right place: Someone contacted me that we should have a repository for Bitcoin Core logos and communication material.
12:49 < jonasschnelli> Somehow that made me think that Bitcoin Core has no clear logo/visual identity. Its not define what to use when, the font, the colors. Not sure if anyone from us cares about that though.
12:49 < paveljanik> press kit? ;-)
12:49 < petertodd> paveljanik: +1
12:50 < jonasschnelli> We probably don't care. But out userbase does a lot
12:50 < petertodd> paveljanik: or maybe call it "media kit" to shift focus to all media in general
12:50 < jonasschnelli> *our
12:50 < btcdrak> jonasschnelli: a press kit would be a good idea
12:50 < wumpus> we don't have that, but if anyone wants to make it and collect some things why not
12:51 < jonasschnelli> It would imply that we first need to create a identity, proper logo, font, etc. I'm not interested ATM, but happy if someone know someone who is.
12:51 < btcdrak> jonaschnelli: ideally we could store that in a "media kit" repository.
12:51 < jonasschnelli> I think it should be a subarea of the website
12:51 < petertodd> jonasschnelli: that makes sense
12:52 < wumpus> yes I think the question is more *who* than if, I don't think press kits are very usual for open source projects, but if someone wants to work on that I don't want to discourage
12:52 < jonasschnelli> Agree.
12:52 < sipa> wumpus: they're very common among altcoins though :p
12:52 < cfields> wumpus: for open-source, they almost always accompany a licensing policy
12:53 < cfields> (lived through that hell for a while in a past life)
12:53 < wumpus> cfields: yes, as for firefox
12:53 < cfields> right
12:53 < cfields> so for us, unless we wanted to police it, a press kit would be more of a collection of recommended images/text that we also use.
12:54 < cfields> i suppose that was the idea, though
12:54 < wumpus> right
12:54 < jonasschnelli> Yes. There is even no clear logo that Bitcoin Core uses/represents.
12:54 < warren>             "\nExamples:\n"
12:54 < warren>             + HelpExampleCli("getnewaddress", "")
12:54 < warren>             + HelpExampleRpc("getnewaddress", "")
12:54 < warren> Any idea why this has both, and they're identical?
12:54 < jonasschnelli> warren: dumpprivatekey
12:55 < wumpus> warren: we're in the middle of a meeting
12:55 < warren> oops sorry!
12:55 < wumpus> well, at the end
12:55 < wumpus> I think we're done
12:55 < jonasschnelli> \ö/
12:55 < wumpus> #endmeeting
12:55 < lightningbot> Meeting ended Thu Apr 28 19:55:37 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:55 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.html
12:55 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.txt
12:55 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.log.html
12:56 < warren> jonasschnelli: ok, not understanding what you mean
12:56 < wumpus> warren: we have cli and rpc examples for all the help items
12:56 < warren> why are they both provided when identical?
12:56 < wumpus> warren: just do 'help getnewaddress' to see what the output is
12:56 < jonasschnelli> warren: nm. RPC does form a different help line then cli
12:56 < wumpus> they aren't identical
12:57 < wumpus> the result is different, they call different functions that have different output, just happens to be with the same arguments
12:57 < warren> oh ok, thanks
12:57 < wumpus> as said, just check 'bitcoin-cli help getnewaddress` and you'll see
13:05 -!- earlest [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
13:06 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 246 seconds]
13:08 < GitHub17> [bitcoin] jonasschnelli opened pull request #7967: [RPC] add feerate option to fundrawtransaction (master...2016/04/fund_fee) https://github.com/bitcoin/bitcoin/pull/7967
13:08 -!- muuqwaul [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
13:14 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
13:14 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Quit: Page closed]
13:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
13:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
13:52 -!- guest78678 [~guest3232@c-67-187-1-225.hsd1.va.comcast.net] has joined #bitcoin-core-dev
13:53 < guest78678> why are we keeping AcceptToMemoryPoolWorker in main?
13:55 -!- xiangfu [~xiangfu@123.125.212.65] has joined #bitcoin-core-dev
13:57 -!- guest78678 [~guest3232@c-67-187-1-225.hsd1.va.comcast.net] has quit [Quit: Leaving]
14:11 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
14:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
14:16 -!- cryptapus_afk is now known as cryptapus
14:24 < instagibbs> did someone volunteer to fix up bip144? missed the last part of meeting
14:36 < btcdrak> instagibbs: it was you iirc.
14:37 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 250 seconds]
14:39 < achow101> instagibbs: I was going to do it in a few minutes if no one else did, but you can do it if you want
14:40 -!- zooko [~user@2602:306:3756:920:30ef:b56b:afe8:670c] has joined #bitcoin-core-dev
14:40 < btcdrak> achow101: I was teasing instagibbs. Go ahead.
14:41 -!- xiangfu [~xiangfu@123.125.212.65] has quit [Ping timeout: 260 seconds]
14:41 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:43  * instagibbs shakes fist at btcdrak 
14:43 < instagibbs> achow101, good, go for it
14:43 < instagibbs> wanted to make sure *someone* was doing it
14:43 < instagibbs> I can review after the fact
14:43 < achow101> which bit is it?
14:44 < instagibbs> not sure, I'd find out, but have family stuff to do
14:44 < instagibbs> I think the service hex is "d"
14:44 < instagibbs> bbl if you still havent figured it out
14:46 < achow101> found it
14:50 -!- grassass [grass@gateway/vpn/mullvad/x-flobadvdduhinjhg] has quit [Remote host closed the connection]
14:53 -!- zooko [~user@2602:306:3756:920:30ef:b56b:afe8:670c] has quit [Ping timeout: 276 seconds]
14:54 < achow101> done https://github.com/bitcoin/bips/pull/380
15:03 -!- lecusemble [~lecusembl@104.233.76.133] has quit [Ping timeout: 252 seconds]
15:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Ping timeout: 250 seconds]
15:05 -!- lecusemble [~lecusembl@104.233.76.133] has joined #bitcoin-core-dev
15:07 < btcdrak> achow101: it's probably worth a mail to the bitcoin-dev list to say we're intending to use the (1 << 3) service bit for segwit.
15:10 < GitHub23> [bitcoin] wtogami opened pull request #7968: doc: Fedora build requirements (master...fedora_build_readme) https://github.com/bitcoin/bitcoin/pull/7968
15:13 < achow101> btcdrak: I'd let sipa do that
15:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
15:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
15:34 -!- cryptapus is now known as cryptapus_afk
15:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
15:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
15:53 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
15:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
15:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
15:57 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:44 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
17:05 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
17:09 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
17:16 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
17:16 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
17:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:16 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
18:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hfaiutmiadaauwit] has quit [Quit: Connection closed for inactivity]
18:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:52 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
19:00 -!- dermoth_ [~thomas@dsl-216-221-56-137.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:01 -!- dermoth_ [~thomas@dsl-216-221-56-137.mtl.aei.ca] has joined #bitcoin-core-dev
19:04 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
19:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
19:11 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]
19:29 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
19:44 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds]
19:48 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
19:52 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
20:27 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
20:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
20:40 -!- Amnez777 [~Amnez777@37.157.216.133] has quit [Ping timeout: 250 seconds]
20:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:41 -!- Amnez777 [~Amnez777@37.157.216.132] has joined #bitcoin-core-dev
20:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:45 -!- Amnez777- [~Amnez777@37.157.216.134] has joined #bitcoin-core-dev
20:48 -!- Amnez777 [~Amnez777@37.157.216.132] has quit [Ping timeout: 252 seconds]
20:54 -!- NotAnNSAgent [~NotAnNSAg@46.166.137.212] has quit [Quit: NotAnNSAgent]
20:55 -!- murch [~murch@p4FDB7812.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
21:23 -!- jtimon [~quassel@79.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
21:28 -!- Amnez777- [~Amnez777@37.157.216.134] has quit [Ping timeout: 250 seconds]
21:33 -!- Amnez777 [~Amnez777@37.157.216.128] has joined #bitcoin-core-dev
21:54 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Quit: AtashiCon]
22:11 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
22:16 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
22:16 -!- matsjj [~matsjj@p20030089EA01982D45BF0BFE567F0750.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
22:17 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
22:22 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
22:35 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
22:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ljhpoavxdpbqulwt] has joined #bitcoin-core-dev
22:55 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer]
22:56 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
22:56 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
23:23 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Quit: AtashiCon]
23:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:30 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
23:32 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Client Quit]
23:39 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
23:41 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Client Quit]
23:46 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
23:52 -!- zooko [~user@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:54 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
23:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
23:57 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev