12016-04-28T00:00:21 <gmaxwell> I think there isn't much point in using memset_s when currently nothing has it, AFAIK.
22016-04-28T00:08:07 <cfields> gmaxwell: iirc it's required by c11? We could get really nasty and add a single c11 file :p
32016-04-28T00:08:14 *** wallet42 has joined #bitcoin-core-dev
42016-04-28T00:10:27 <luke-jr> C11 != C++11
52016-04-28T00:10:56 <cfields> luke-jr: right, hence the single c11 file
62016-04-28T00:11:21 <randy-waterhouse> cfields: re https://github.com/bitcoin/bitcoin/pull/7165 I dont think libsecpk251 requires c++11 ... or does it?
72016-04-28T00:11:23 <luke-jr> ah, with a function call to it from C++?
82016-04-28T00:11:35 <luke-jr> libsecpk251 is C89 IIRC
92016-04-28T00:11:38 <cfields> luke-jr: yea. That wasn't a real suggestion, though
102016-04-28T00:11:59 <luke-jr> oh, lol
112016-04-28T00:13:05 <cfields> randy-waterhouse: ^^. That doesn't change anything for libsecp256k1
122016-04-28T00:14:39 <randy-waterhouse> but the other dependencies now are all built using c++11
132016-04-28T00:15:04 <cfields> randy-waterhouse: the c++ ones are. The c deps don't change
142016-04-28T00:15:35 <randy-waterhouse> ah ok, lost sight of bigger picture
152016-04-28T00:16:09 <sipa> i wonder if compiling libsecp256k1 with c++11 would work (without any extern "C" { blocks, i mean)
162016-04-28T00:16:17 <cfields> sipa: yep
172016-04-28T00:16:23 <cfields> sipa: c++14, at least
182016-04-28T00:16:32 <sipa> ha
192016-04-28T00:16:37 <cfields> i played with it a while back to see what i could make constexpr
202016-04-28T00:16:49 <cfields> iirc there were 1 or 2 explicit casts needed, but nothing else
212016-04-28T00:16:58 <sipa> interesting
222016-04-28T00:17:09 * sipa used git rerere for the first time today
232016-04-28T00:17:32 <cfields> sipa: ah damn, i meant to remind you about that at last week's meeting
242016-04-28T00:18:01 <cfields> makes segwit rebasing a bit easier, i hope?
252016-04-28T00:18:16 <sipa> i'm not rebasing segwit
262016-04-28T00:18:32 <sipa> not until right before merge
272016-04-28T00:18:56 <sipa> plan is to just add fixup commits, and have a single merge with master commit at the end
282016-04-28T00:18:57 <cfields> oh, i figured you had a local branch that you were rebasing along the way
292016-04-28T00:19:08 *** laurentmt has joined #bitcoin-core-dev
302016-04-28T00:19:18 <cfields> gotcha
312016-04-28T00:24:32 *** cryptapus_ has joined #bitcoin-core-dev
322016-04-28T00:24:38 *** cryptapus_ is now known as cryptapus_afk
332016-04-28T00:24:55 *** cryptapus has quit IRC
342016-04-28T00:28:48 <luke-jr> sipa: I used to use git-rerere, but I found it too dangerous
352016-04-28T00:40:24 *** AaronvanW has quit IRC
362016-04-28T00:41:23 <gmaxwell> cfields: I don't think it's required, I think it's in an appendix.
372016-04-28T00:50:12 *** laurentmt has quit IRC
382016-04-28T00:56:16 *** frankenmint has joined #bitcoin-core-dev
392016-04-28T01:01:08 *** Ylbam has quit IRC
402016-04-28T01:07:44 *** cryptapus_afk is now known as cryptapus_
412016-04-28T01:07:46 *** cryptapus_ is now known as cryptapus
422016-04-28T01:14:45 *** cryptapus is now known as cryptapus_afk
432016-04-28T01:15:58 *** Chris_Stewart_5 has quit IRC
442016-04-28T01:20:57 *** aburan28 has quit IRC
452016-04-28T01:23:01 *** fengling has joined #bitcoin-core-dev
462016-04-28T01:29:07 *** Chris_Stewart_5 has joined #bitcoin-core-dev
472016-04-28T01:32:47 *** belcher has quit IRC
482016-04-28T01:39:03 <achow101> would it be possible, for after segwit deployment, to have a command line option to have Bitcoin Core write blocks to the disk in the pre-fork block forkmat?
492016-04-28T01:47:42 <gmaxwell> achow101: it needs the data itself... the block files really aren't meant to be consumed by external software.
502016-04-28T01:51:05 *** Chris_Stewart_5 has quit IRC
512016-04-28T01:57:14 <achow101> Yeah, I realize that and the situation is non-ideal. I just thought that it might be possible to prune the segwit data to maintain backwards compatibility with software like Armory
522016-04-28T02:06:56 *** NotAnNSAgent has quit IRC
532016-04-28T02:07:15 *** NotAnNSAgent has joined #bitcoin-core-dev
542016-04-28T02:10:39 *** frankenmint has quit IRC
552016-04-28T02:39:25 <GitHub154> [bitcoin] 21E14 opened pull request #7962: CalculateNextWorkRequired Cleanup (master...cleanpow) https://github.com/bitcoin/bitcoin/pull/7962
562016-04-28T02:54:03 *** frankenmint has joined #bitcoin-core-dev
572016-04-28T02:58:47 *** TomMc has joined #bitcoin-core-dev
582016-04-28T03:12:02 *** luke-jr has quit IRC
592016-04-28T03:13:09 *** TomMc has quit IRC
602016-04-28T03:15:38 *** luke-jr has joined #bitcoin-core-dev
612016-04-28T03:32:01 *** Alopex has quit IRC
622016-04-28T03:33:07 *** Alopex has joined #bitcoin-core-dev
632016-04-28T03:48:01 *** Alopex has quit IRC
642016-04-28T03:49:06 *** Alopex has joined #bitcoin-core-dev
652016-04-28T03:57:11 *** roidster has quit IRC
662016-04-28T04:07:20 *** xiangfu has joined #bitcoin-core-dev
672016-04-28T04:08:24 *** droark has joined #bitcoin-core-dev
682016-04-28T04:09:33 *** molz has joined #bitcoin-core-dev
692016-04-28T04:10:33 *** PRab_ has joined #bitcoin-core-dev
702016-04-28T04:11:59 *** PRab has quit IRC
712016-04-28T04:12:06 *** PRab_ is now known as PRab
722016-04-28T04:13:34 *** moli has quit IRC
732016-04-28T04:25:30 <NotAnNSAgent> verificationprogress: 0.86206621
742016-04-28T04:25:38 <NotAnNSAgent> Zzz... it's been many days.
752016-04-28T04:40:03 *** NotAnNSAgent has quit IRC
762016-04-28T05:04:07 *** frankenmint has quit IRC
772016-04-28T05:04:41 *** frankenmint has joined #bitcoin-core-dev
782016-04-28T05:08:22 *** frankenmint has quit IRC
792016-04-28T05:08:40 *** frankenmint has joined #bitcoin-core-dev
802016-04-28T05:09:04 *** supasonic has quit IRC
812016-04-28T05:09:31 *** supasonic has joined #bitcoin-core-dev
822016-04-28T05:12:27 *** BonyM has joined #bitcoin-core-dev
832016-04-28T05:30:36 *** fengling has quit IRC
842016-04-28T05:51:39 *** grassass has joined #bitcoin-core-dev
852016-04-28T05:54:59 *** ThomasV has joined #bitcoin-core-dev
862016-04-28T05:56:42 *** Ylbam has joined #bitcoin-core-dev
872016-04-28T06:00:44 *** arowser_ has quit IRC
882016-04-28T06:01:14 *** arowser has joined #bitcoin-core-dev
892016-04-28T06:07:37 *** jtimon has quit IRC
902016-04-28T06:25:52 *** BashCo has quit IRC
912016-04-28T06:35:34 *** ThomasV has quit IRC
922016-04-28T06:48:46 *** BashCo has joined #bitcoin-core-dev
932016-04-28T07:01:11 *** fengling has joined #bitcoin-core-dev
942016-04-28T07:43:02 *** Alopex has quit IRC
952016-04-28T07:44:07 *** Alopex has joined #bitcoin-core-dev
962016-04-28T07:52:12 *** Amnez777 has quit IRC
972016-04-28T07:57:30 *** Hmmmm has joined #bitcoin-core-dev
982016-04-28T08:04:35 *** cjcj has joined #bitcoin-core-dev
992016-04-28T08:11:17 *** AaronvanW has joined #bitcoin-core-dev
1002016-04-28T08:12:50 *** Thireus has quit IRC
1012016-04-28T08:22:01 *** cryptapus_afk has quit IRC
1022016-04-28T08:22:29 *** supasonic has quit IRC
1032016-04-28T08:23:28 *** Hmmmm has quit IRC
1042016-04-28T08:24:59 *** cryptapus_afk has joined #bitcoin-core-dev
1052016-04-28T08:25:18 *** Thireus has joined #bitcoin-core-dev
1062016-04-28T08:52:23 <GitHub149> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/08b37c5e06bf...06162f19d7dd
1072016-04-28T08:52:24 <GitHub149> bitcoin/master 67969af Wladimir J. van der Laan: build: Enable C++11 build, require C++11 compiler...
1082016-04-28T08:52:24 <GitHub149> bitcoin/master a398549 Cory Fields: depends: use c++11
1092016-04-28T08:52:25 <GitHub149> bitcoin/master 2aacc72 Wladimir J. van der Laan: build: update ax_cxx_compile_stdcxx to serial 4
1102016-04-28T08:52:48 <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
1112016-04-28T08:53:25 <gmaxwell> hurray
1122016-04-28T08:57:57 <wumpus> yeahhh finally
1132016-04-28T09:10:42 <sipa> \o/
1142016-04-28T09:11:00 *** Guyver2 has joined #bitcoin-core-dev
1152016-04-28T09:11:48 <wumpus> jonasschnelli: FYI (reading your post in #7917) debug.logs compress *very* well
1162016-04-28T09:12:14 <jonasschnelli> Right. Was to lazy.
1172016-04-28T09:12:18 <wumpus> heh
1182016-04-28T09:12:20 <jonasschnelli> At least i should enable mod_deflate
1192016-04-28T09:12:25 <jonasschnelli> (for apache)
1202016-04-28T09:14:19 <wumpus> right, that'd at least save bandwidth
1212016-04-28T09:14:49 <jonasschnelli> Post #7165 means we can use C++11 features now? Right? Core will no longer compile on non C++11 compilers?
1222016-04-28T09:16:18 <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.
1232016-04-28T09:16:18 <sipa> i wonder how much performance we gained :)
1242016-04-28T09:17:04 <jonasschnelli> Hmm... is there no plan for removing the boost beast longterm?
1252016-04-28T09:17:29 <gmaxwell> Absolutely, but not now.
1262016-04-28T09:17:32 <wumpus> yes, we can use C++11 features now
1272016-04-28T09:17:57 <jonasschnelli> So, new code will use c++11 foreachs old code still sticks with BOOST_FOREACH?
1282016-04-28T09:17:59 <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
1292016-04-28T09:18:10 <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)
1302016-04-28T09:18:16 <wumpus> using it in things that are new features in 0.13 anyhow is fine
1312016-04-28T09:18:17 <sipa> i think converting sync.h to use std::thread would be fine, for example
1322016-04-28T09:18:24 <jonasschnelli> gmaxwell: good point!
1332016-04-28T09:18:25 <sipa> as it is very unlikely to conflict with anything
1342016-04-28T09:18:35 <sipa> but yes, don't go all over the code to convert everything
1352016-04-28T09:18:39 <wumpus> sipa: definitely, that is very unlikely to have to be changed for segwit, or anything backported
1362016-04-28T09:18:42 <gmaxwell> self contained things... yep, new features. yep.
1372016-04-28T09:18:57 <wumpus> so for the utilities and such: fine
1382016-04-28T09:19:28 <jonasschnelli> Okay. Are there any c++11 features we should avoid? Like atomics?
1392016-04-28T09:19:45 <wumpus> after segwit is merged to 0.12 I don't care anymore and IMO we can go full c++11 crazy
1402016-04-28T09:20:01 <wumpus> (keeping in mind the risks that refactors always bring, of course)
1412016-04-28T09:20:30 <jonasschnelli> Right. I agree with gmaxwell: As long as we support 0.12 (non C++11) we should not refactor to much
1422016-04-28T09:20:52 <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
1432016-04-28T09:21:05 <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.
1442016-04-28T09:21:20 <sipa> https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
1452016-04-28T09:21:38 <sipa> 4.7 has atomics
1462016-04-28T09:21:46 <wumpus> nice
1472016-04-28T09:22:04 *** pedrobranco has joined #bitcoin-core-dev
1482016-04-28T09:22:18 <gmaxwell> (like, for example, they might get used in the RNG.. but most places should just use conventional locking)
1492016-04-28T09:22:48 <wumpus> right, definitely use convential locking unless there is a specific performance bottleneck where atomics wuld help a lot
1502016-04-28T09:22:55 <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)
1512016-04-28T09:23:00 * sipa wants: auto, range for, rvalue references/moves, std::thread etc, nullptr, override, initializer lists
1522016-04-28T09:23:12 <wumpus> code using atomics is usually even harder to review
1532016-04-28T09:23:19 <gmaxwell> priorities should be changes that improve code safty, and changes that eliminate dependency on boost.
1542016-04-28T09:23:25 <gmaxwell> once refactoring changes start.
1552016-04-28T09:23:25 <wumpus> (unless it is for really trivial things like counters ...)
1562016-04-28T09:23:56 <gmaxwell> wumpus: even with counters, you seldom have just one counter... :)
1572016-04-28T09:24:23 <wumpus> right
1582016-04-28T09:24:29 <sipa> for example for the debug=bench counters, atomics could be used i think?
1592016-04-28T09:24:45 *** Amnez777 has joined #bitcoin-core-dev
1602016-04-28T09:24:48 <sipa> all you need is += and get
1612016-04-28T09:25:19 <gmaxwell> so long as you don't care if a print isn't mixing up data from seperate runs... for benchmarking its probably okay...
1622016-04-28T09:25:34 <sipa> yeah
1632016-04-28T09:26:16 <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
1642016-04-28T09:26:20 <wumpus> the debug=bench counters/accumulators are all used one at a time anyway afaik
1652016-04-28T09:26:21 <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.
1662016-04-28T09:27:48 <jonasschnelli> Call for a quick review: https://github.com/bitcoin/bitcoin/pull/7826 (<-- this will allow to GUI to display RBF conflicts)
1672016-04-28T09:30:22 <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...
1682016-04-28T09:31:29 <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.
1692016-04-28T09:31:42 <wumpus> (e.g. as if something is really wrong)
1702016-04-28T09:32:14 <wumpus> but in any case your pull is a clear step forward
1712016-04-28T09:32:46 <sipa> gmaxwell: aware (look at the crc code that you're running for me :p)
1722016-04-28T09:32:50 <wumpus> better than showing both in the same way as waiting to be confirmed
1732016-04-28T09:33:08 <wumpus> crc code?
1742016-04-28T09:33:11 <jonasschnelli> wumpus: Right. I guess only RBF can result in a mempool conflict. So using a other icon should be fine.
1752016-04-28T09:33:14 <jonasschnelli> Let me overhaul it.
1762016-04-28T09:33:24 <sipa> wumpus: i'm benchmarking some crcs for a base32 address format :)
1772016-04-28T09:34:08 <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)
1782016-04-28T09:34:24 <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? :)
1792016-04-28T09:34:33 <wumpus> that's all for crc32c though as that's the one in leveldb
1802016-04-28T09:35:01 <jonasschnelli> JackH: you are writing a new command (dev) or using a existing one (non-dev)?
1812016-04-28T09:35:43 <sipa> wumpus: benchmarking how well they detect errors, not performance
1822016-04-28T09:35:51 <wumpus> ohh okay
1832016-04-28T09:35:52 <sipa> wumpus: https://github.com/sipa/ezbase32
1842016-04-28T09:36:41 <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?
1852016-04-28T09:36:57 <sipa> JackH: settxfee modifies a global setting
1862016-04-28T09:37:09 <wumpus> do the settxfee before the sendfrom
1872016-04-28T09:37:10 <sipa> JackH: you need to run them separately
1882016-04-28T09:37:36 <sipa> also, sendfrom will by default include a fee, based on estimations
1892016-04-28T09:37:37 <JackH> ahh it modifies the global. So should I instead edit the .conf file and then do the sendfrom?
1902016-04-28T09:37:53 <sipa> wumpus: latest development is a BCH code over GF(2^32) that guarantees detecting 4 errors with 6 base32 checksum
1912016-04-28T09:38:04 <sipa> eh over GF(2^5)
1922016-04-28T09:38:11 * jonasschnelli thinks we should probably add a optional feerate parameter to fundrawtransaction
1932016-04-28T09:38:22 <wumpus> jonasschnelli: there isn't one yet?
1942016-04-28T09:38:31 * jonasschnelli looking..
1952016-04-28T09:38:39 <wumpus> I'm surprised, would be so much better than changing a global
1962016-04-28T09:38:57 <jonasschnelli> no.. i don't think so. Maybe there is a PR.
1972016-04-28T09:39:03 <sipa> there is a pr
1982016-04-28T09:39:03 <jonasschnelli> Hard to keep track of everything. :)
1992016-04-28T09:39:06 <wumpus> no, the PR does it wrong
2002016-04-28T09:39:19 <jonasschnelli> It was an absolute fee IIRC
2012016-04-28T09:39:38 <jonasschnelli> you pass in a feerate that one could determine with estimatefee
2022016-04-28T09:39:45 <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
2032016-04-28T09:40:08 <jonasschnelli> The ugly thing is, that CreateTransaction uses the static DEFAULT_TARGET
2042016-04-28T09:40:17 <wumpus> passing in an optional feerate would be the obvious thing to do
2052016-04-28T09:40:20 <jonasschnelli> So, this would require some refactoring.
2062016-04-28T09:40:34 <sipa> just add a confirmation target to coincontrol
2072016-04-28T09:40:47 <jonasschnelli> Yes. This sounds good.
2082016-04-28T09:40:47 <wumpus> right, just slap it into coincontrol
2092016-04-28T09:40:56 <sipa> wasn't there a PR that added a bunch of options to fundrawtransaction?
2102016-04-28T09:40:59 <sipa> including that
2112016-04-28T09:41:04 <jonasschnelli> Not the feerate.
2122016-04-28T09:41:10 <jonasschnelli> But the rest is merged.
2132016-04-28T09:41:12 *** MarcoFalke has joined #bitcoin-core-dev
2142016-04-28T09:41:24 <jonasschnelli> Which finally allows me to write my iOS Core Wallet client
2152016-04-28T09:41:27 <wumpus> we have a bunch of options in fundrawtransactions, which is why I was confused
2162016-04-28T09:41:39 <wumpus> yes that one was merged
2172016-04-28T09:41:46 <jonasschnelli> (keep keys on smartphone, use watchonly core wallet, use fundrawtransactin, sign on the smartphone)
2182016-04-28T09:41:52 <wumpus> jonasschnelli: nice
2192016-04-28T09:42:31 <wumpus> sipa: how does that compare to standard CRC32?
2202016-04-28T09:42:36 <jonasschnelli> It really made me thing that the wallet (in watchonly mode) is just a utility to keep track of user-(group-)relevant transactions.
2212016-04-28T09:42:51 <jonasschnelli> like a selective tx-/address-index
2222016-04-28T09:42:58 <wumpus> jonasschnelli: it is
2232016-04-28T09:43:08 <wumpus> joinmarket uses it the same way
2242016-04-28T09:43:25 <sipa> wumpus: a CRC32 isn't compatible with base32 (as it would produce 6.4 characters)
2252016-04-28T09:43:47 <sipa> wumpus: i'm including a CRC30 though, and it seems to perform way better than the theory would predict
2262016-04-28T09:46:03 <wumpus> sipa: ah right, get it now, output needs to be a multiple of 5 bits, not 32 bit
2272016-04-28T09:46:42 <sipa> right, it's a checksum on base32 elements, so it takes a series of base32 tokens, and produces 6 extra ones
2282016-04-28T09:47:17 <wumpus> instead of doing the checksum before the encoding, you do it afterward on the encoding itself
2292016-04-28T09:47:39 <wumpus> I suppose that does make it easier to reason about the properties, yes
2302016-04-28T09:48:19 <wumpus> and it's also slightly more convenient, no need to decode to check
2312016-04-28T10:06:32 <sipa> indeed, though decoding base32 is sufficiently simple that it does not really matter
2322016-04-28T10:06:46 <wumpus> yes it's not so unfortunate as base58
2332016-04-28T10:15:56 *** Evel-Knievel has quit IRC
2342016-04-28T10:21:51 <GitHub185> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/06162f19d7dd...574ddc63d6ff
2352016-04-28T10:21:52 <GitHub185> bitcoin/master 17a6a21 Wladimir J. van der Laan: qt: Make it possible to show details for multiple transactions...
2362016-04-28T10:21:52 <GitHub185> bitcoin/master f135e3c Wladimir J. van der Laan: qt: Add transaction hash to details window title
2372016-04-28T10:21:53 <GitHub185> bitcoin/master 574ddc6 Wladimir J. van der Laan: Merge #7939: qt: Make it possible to show details for multiple transactions...
2382016-04-28T10:22:01 <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
2392016-04-28T10:22:46 *** ghtdak has quit IRC
2402016-04-28T10:23:26 *** ghtdak has joined #bitcoin-core-dev
2412016-04-28T10:25:50 *** arowser has quit IRC
2422016-04-28T10:26:07 *** arowser has joined #bitcoin-core-dev
2432016-04-28T10:35:08 *** cjcj has quit IRC
2442016-04-28T10:56:00 <GitHub110> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/574ddc63d6ff...d9594bfe0c3e
2452016-04-28T10:56:00 <GitHub110> bitcoin/master 8aa7226 jmacwhyte: Fix IsInitialBlockDownload to play nice with testnet
2462016-04-28T10:56:01 <GitHub110> bitcoin/master d9594bf Wladimir J. van der Laan: Merge #7514: Fix IsInitialBlockDownload for testnet...
2472016-04-28T10:56:05 <GitHub167> [bitcoin] laanwj closed pull request #7514: Fix IsInitialBlockDownload for testnet (master...fixisinitialblock) https://github.com/bitcoin/bitcoin/pull/7514
2482016-04-28T11:32:11 *** pmienk has quit IRC
2492016-04-28T11:34:46 <wumpus> re: c++11 refactoring, we should convert the auto_ptrs to unique_ptrs IMO
2502016-04-28T11:36:44 <sipa> i'm seeing the very strange error "Insufficient funds" in listtransactions.py (segwit branch, but nothing should have changed there)
2512016-04-28T11:36:53 <sipa> but only when i run it through rpc-tests
2522016-04-28T11:37:15 <sipa> if i run it standalone it works
2532016-04-28T11:37:22 <sipa> is there any difference in setup between them?
2542016-04-28T11:37:35 <wumpus> try deleting all cache directories
2552016-04-28T11:38:40 <wumpus> otherwise, no, there is no difference in setup, rpc-tests simply starts the individual tests as processes
2562016-04-28T11:39:58 *** cryptapus has joined #bitcoin-core-dev
2572016-04-28T11:45:03 <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
2582016-04-28T11:45:32 *** NotAnNSAgent has joined #bitcoin-core-dev
2592016-04-28T11:48:22 *** dermoth_ has joined #bitcoin-core-dev
2602016-04-28T11:51:44 *** dermoth has quit IRC
2612016-04-28T11:53:23 <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9594bfe0c3e...a9c8b744e887
2622016-04-28T11:53:23 <GitHub168> bitcoin/master 61c0170 Pavel JanÃk: Log invalid block hash to make debugging easier.
2632016-04-28T11:53:24 <GitHub168> bitcoin/master a9c8b74 Wladimir J. van der Laan: Merge #7952: Log invalid block hash to make debugging easier....
2642016-04-28T11:53:33 <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
2652016-04-28T12:08:39 *** xiangfu has quit IRC
2662016-04-28T12:10:36 *** fengling has quit IRC
2672016-04-28T12:13:07 *** Evel-Knievel has joined #bitcoin-core-dev
2682016-04-28T12:32:13 *** randy-waterhouse has quit IRC
2692016-04-28T12:36:02 <GitHub95> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a9c8b744e887...5725807402ec
2702016-04-28T12:36:02 <GitHub95> bitcoin/master 9c0bcb6 instagibbs: push back getaddednodeinfo dead value
2712016-04-28T12:36:03 <GitHub95> bitcoin/master 5725807 Wladimir J. van der Laan: Merge #7926: [RPC] push back getaddednodeinfo dead value...
2722016-04-28T12:36:07 <GitHub86> [bitcoin] laanwj closed pull request #7926: [RPC] push back getaddednodeinfo dead value (master...getaddedpushbackmaster) https://github.com/bitcoin/bitcoin/pull/7926
2732016-04-28T12:48:36 *** BonyM has quit IRC
2742016-04-28T12:48:44 *** jtimon has joined #bitcoin-core-dev
2752016-04-28T12:53:04 *** BonyM has joined #bitcoin-core-dev
2762016-04-28T13:10:42 *** laurentmt has joined #bitcoin-core-dev
2772016-04-28T13:15:28 *** Amnez777 has quit IRC
2782016-04-28T13:16:51 *** Amnez777 has joined #bitcoin-core-dev
2792016-04-28T13:32:10 *** Giszmo has joined #bitcoin-core-dev
2802016-04-28T13:34:05 <GitHub81> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5725807402ec...20f9ecd343bb
2812016-04-28T13:34:05 <GitHub81> bitcoin/master c7aac2d 21E14: Deprecating the remaining LogPrintf dependencies that were made obsolete in PR #7459.
2822016-04-28T13:34:06 <GitHub81> bitcoin/master 20f9ecd Wladimir J. van der Laan: Merge #7962: CalculateNextWorkRequired Cleanup...
2832016-04-28T13:34:11 <GitHub69> [bitcoin] laanwj closed pull request #7962: CalculateNextWorkRequired Cleanup (master...cleanpow) https://github.com/bitcoin/bitcoin/pull/7962
2842016-04-28T13:40:40 *** jtimon_ has joined #bitcoin-core-dev
2852016-04-28T13:40:52 *** jtimon_ has quit IRC
2862016-04-28T13:53:52 *** shesek has quit IRC
2872016-04-28T13:57:29 *** cryptapus_ has joined #bitcoin-core-dev
2882016-04-28T13:59:08 *** TomMc has joined #bitcoin-core-dev
2892016-04-28T14:01:15 *** cryptapus has quit IRC
2902016-04-28T14:15:53 *** laurentmt has quit IRC
2912016-04-28T14:22:12 *** cryptapus_ has quit IRC
2922016-04-28T14:22:26 *** cryptapus_ has joined #bitcoin-core-dev
2932016-04-28T14:26:09 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2942016-04-28T14:29:54 *** cryptapus_ is now known as cryptapus
2952016-04-28T14:46:28 *** shesek has joined #bitcoin-core-dev
2962016-04-28T15:03:02 *** frankenmint has quit IRC
2972016-04-28T15:19:15 *** Guyver2_ has joined #bitcoin-core-dev
2982016-04-28T15:20:12 *** Guyver2 has quit IRC
2992016-04-28T15:20:19 *** Guyver2_ is now known as Guyver2
3002016-04-28T15:23:06 <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,"
3012016-04-28T15:23:14 <Chris_Stewart_5> Shouldn't 'input' be changed to 'output'?
3022016-04-28T15:23:40 <Chris_Stewart_5> this is in BIP112
3032016-04-28T15:40:25 *** supasonic has joined #bitcoin-core-dev
3042016-04-28T15:46:17 <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?
3052016-04-28T15:46:37 <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.
3062016-04-28T15:48:17 *** Chris_Stewart_5 has quit IRC
3072016-04-28T15:50:26 <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 ...
3082016-04-28T15:50:32 <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?
3092016-04-28T15:51:02 *** BashCo has quit IRC
3102016-04-28T15:52:32 <kanzure> alternatively: how much overhead is _batch rpc stuff in comparison to a single rpc call like a hypothetical "getallblockhashes"?
3112016-04-28T15:55:15 <wumpus> pretty much the same
3122016-04-28T15:56:04 <wumpus> the RPC batching functionality is severly underused, an example is contrib/linearize
3132016-04-28T15:56:35 <instagibbs> wumpus, so, how do I use it
3142016-04-28T15:56:36 <wumpus> it requests all the block hashes, though not in a way that copes with reorgs
3152016-04-28T15:56:48 <wumpus> (it's meant as one-shot)
3162016-04-28T15:57:01 <kanzure> https://github.com/bitcoin/bitcoin/blob/7fc25c2e5d493f4ef46c9b5831d92886bcea17a8/contrib/linearize/linearize-hashes.py#L64
3172016-04-28T15:57:08 <kanzure> oh this is using an interval
3182016-04-28T15:57:24 <kanzure> alright well, my method copes with reorgs by grabbing all blockhashes
3192016-04-28T15:57:47 <sipa> https://github.com/sipa/bitcoin-stats/blob/master/keepdump.pl
3202016-04-28T15:57:58 <sipa> that maintains a list of all blocks in a text file
3212016-04-28T15:58:05 <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?
3222016-04-28T15:58:08 <sipa> it also doesn't deal with reorgs, as it just puts all blocks there
3232016-04-28T15:58:19 <sipa> kanzure: nope, in memory
3242016-04-28T15:58:21 <sipa> :p
3252016-04-28T15:58:35 <kanzure> in memory sounds good, that should be fast to dump over rpc
3262016-04-28T15:58:41 <kanzure> yeah we should do this
3272016-04-28T15:58:53 <sipa> sounds like something for the REST interface
3282016-04-28T15:59:07 <sipa> actually, doesn't it already have that?
3292016-04-28T15:59:11 <sipa> fetching a range of block headers
3302016-04-28T15:59:25 <kanzure> range is incompatible with reorgs
3312016-04-28T16:00:07 <kanzure> you can do range + confirmationwaitdepth i guess (where confirmationwaitdepth is your risk threshold for accepting deposits or payments or whatever)
3322016-04-28T16:00:27 <wumpus> kanzure: until http streaming is implemented we don't really want anything that returns that much data
3332016-04-28T16:00:57 <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.
3342016-04-28T16:01:09 <wumpus> in the meantime just use batching
3352016-04-28T16:01:22 <kanzure> but... it's slow.
3362016-04-28T16:01:30 <sipa> kanzure: you only need to call it a few 100000 times at first startup
3372016-04-28T16:01:37 <wumpus> REST is much faster than using getblock
3382016-04-28T16:01:49 <sipa> kanzure: after that you just look at the tip, and go backwards to update your best known state
3392016-04-28T16:01:49 <wumpus> saves the encoding overhead as first hex then JSON
3402016-04-28T16:01:59 <kanzure> getblock isn't the problem, i'm using _batch with getblockhash only
3412016-04-28T16:02:01 <wumpus> and you can pipeline requests on the same TCP connection
3422016-04-28T16:02:31 <wumpus> also how many times do you expect to do this? is ten seconds really a problem?
3432016-04-28T16:02:33 <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.
3442016-04-28T16:02:48 <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.
3452016-04-28T16:02:58 <sipa> kanzure: i don't understand why you need to see all hashes
3462016-04-28T16:03:02 <wumpus> increase your socket timeout
3472016-04-28T16:03:09 <wumpus> it's the client that timeouts, never the server
3482016-04-28T16:03:22 <wumpus> server won't timeout while it's working and not waiting for client input
3492016-04-28T16:03:22 <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.
3502016-04-28T16:03:34 <sipa> kanzure: no, that is not what i mean
3512016-04-28T16:04:02 <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
3522016-04-28T16:04:11 <kanzure> wumpus: correct. it's definitely the client that is timing out.
3532016-04-28T16:04:13 <wumpus> FYI my attempt at http streaming (still kind of unstable) https://github.com/bitcoin/bitcoin/pull/7759
3542016-04-28T16:04:34 <wumpus> kanzure: the default timeout is set to 30 seconds or so, that's not a lot, esp if you're batching
3552016-04-28T16:05:01 <wumpus> instagibbs: linearize provides an example, I should also have a very simple proof of concept somewhere but can't find it right now
3562016-04-28T16:05:07 <kanzure> sipa: i guess i could limit the getblockhash calls in my _batch request, to be (blockheight in database) minus (200 confirmations) or something.
3572016-04-28T16:05:23 <kanzure> wumpus: is that server or client socket timeout default?
3582016-04-28T16:05:27 <sipa> kanzure: i think using batching is overkill; just go one by one
3592016-04-28T16:05:33 <kanzure> sipa: that takes a lot longer.
3602016-04-28T16:05:44 <sipa> in almost all cases you just need 1 call!
3612016-04-28T16:05:49 <wumpus> kanzure: I don't know, check for yourself
3622016-04-28T16:05:56 <wumpus> (it depends on what client library you use)
3632016-04-28T16:05:59 *** pmienk has joined #bitcoin-core-dev
3642016-04-28T16:06:43 <kanzure> sipa: hmm okay. right.
3652016-04-28T16:06:50 <wumpus> with python authserviceproxy you can simply specify it in the constructor
3662016-04-28T16:07:02 <wumpus> instagibbs: https://gist.github.com/laanwj/f2e0238bd151d5365c07bdd03467588b
3672016-04-28T16:09:32 <kanzure> wumpus: sipa: thank you.
3682016-04-28T16:22:34 *** BCBot has joined #bitcoin-core-dev
3692016-04-28T16:24:00 *** cdecker has joined #bitcoin-core-dev
3702016-04-28T16:25:08 *** cdecker has quit IRC
3712016-04-28T16:26:16 <instagibbs> cool thanks
3722016-04-28T16:34:32 *** BashCo has joined #bitcoin-core-dev
3732016-04-28T16:40:31 *** Thireus1 has joined #bitcoin-core-dev
3742016-04-28T16:40:41 *** Thireus has quit IRC
3752016-04-28T16:42:35 *** BCBot has quit IRC
3762016-04-28T16:42:42 *** BCBot has joined #bitcoin-core-dev
3772016-04-28T16:57:25 *** earlest has joined #bitcoin-core-dev
3782016-04-28T17:00:34 *** bysherper has quit IRC
3792016-04-28T17:01:58 *** bysherper has joined #bitcoin-core-dev
3802016-04-28T17:04:24 *** MarcoFalke has quit IRC
3812016-04-28T17:05:04 *** earlest has quit IRC
3822016-04-28T17:07:50 <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
3832016-04-28T17:26:56 *** wallet421 has joined #bitcoin-core-dev
3842016-04-28T17:32:17 *** pmienk has quit IRC
3852016-04-28T17:32:25 *** laurentmt has joined #bitcoin-core-dev
3862016-04-28T17:44:47 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3872016-04-28T17:45:16 *** molz has quit IRC
3882016-04-28T17:48:16 *** pmienk has joined #bitcoin-core-dev
3892016-04-28T18:01:19 *** laurentmt has quit IRC
3902016-04-28T18:05:14 *** moli has joined #bitcoin-core-dev
3912016-04-28T18:14:36 *** pedrobranco has quit IRC
3922016-04-28T18:17:59 *** pedrobranco has joined #bitcoin-core-dev
3932016-04-28T18:22:20 *** pedrobranco has quit IRC
3942016-04-28T18:27:14 *** belcher has joined #bitcoin-core-dev
3952016-04-28T18:29:24 *** treehug88 has joined #bitcoin-core-dev
3962016-04-28T18:35:27 *** pedrobranco has joined #bitcoin-core-dev
3972016-04-28T18:36:34 *** bysherper has quit IRC
3982016-04-28T18:36:46 *** wallet421 has quit IRC
3992016-04-28T18:39:59 *** pedrobranco has quit IRC
4002016-04-28T18:50:17 *** Guest45728 has joined #bitcoin-core-dev
4012016-04-28T18:50:50 <jonasschnelli> why does CFeeRate has not setter?
4022016-04-28T18:51:02 <jonasschnelli> Or am I missing something?
4032016-04-28T18:51:48 *** Guest45728 is now known as roidster
4042016-04-28T18:56:25 *** cjcj has joined #bitcoin-core-dev
4052016-04-28T18:57:25 <wumpus> it's just a value, if you need to assign a new value just assign a new CFeeRate(...) object
4062016-04-28T18:57:39 *** BonyM has quit IRC
4072016-04-28T18:57:57 <wumpus> no need to be able to change it partially
4082016-04-28T18:57:57 <jonasschnelli> Right. But overloading = op. with a CAmount would be something. Not?
4092016-04-28T18:58:13 <wumpus> I don't think that's necessary
4102016-04-28T18:58:25 <wumpus> (sounds slightly confusing to me)
4112016-04-28T18:58:27 <jonasschnelli> But right. feeRate = CFeeRate(new) is fine.
4122016-04-28T18:58:36 <wumpus> better to be explicit
4132016-04-28T18:59:28 <gmaxwell> Meeting time soon.
4142016-04-28T18:59:49 <jonasschnelli> jtimon: meeting now.
4152016-04-28T19:00:09 <jtimon> thanks
4162016-04-28T19:00:11 <wumpus> #startmeeting
4172016-04-28T19:00:11 <lightningbot> Meeting started Thu Apr 28 19:00:11 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4182016-04-28T19:00:11 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4192016-04-28T19:00:12 <gmaxwell> sipa: jonasschnelli wumpus morcos sdaftuar kanzure BlueMatt jtimon cfields luke-jr petertodd
4202016-04-28T19:00:29 <wumpus> proposed topics?
4212016-04-28T19:00:30 <sipa> mildly present
4222016-04-28T19:00:48 <kanzure> i propose follow-up from last week re: segwit code review, and new/upcoming tasks on that front
4232016-04-28T19:00:50 <morcos> i'm here for 10 mins
4242016-04-28T19:01:02 <kanzure> gmaxwell: thanks for the ping
4252016-04-28T19:01:03 <jonasschnelli> I have two very small topic proposals: wording for RBF, a request for creating/storing CI material
4262016-04-28T19:01:05 <gmaxwell> morcos: anything you want to talk about in 10 minutes.
4272016-04-28T19:01:10 <cfields> thanks, here
4282016-04-28T19:01:25 *** chris2000 has joined #bitcoin-core-dev
4292016-04-28T19:01:31 <morcos> just to encourage anyone who is going to review segwit to get on it! :)
4302016-04-28T19:01:56 <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
4312016-04-28T19:01:56 <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 :)
4322016-04-28T19:01:59 <gmaxwell> What is the status of the segwit BIPs? are they all consistent with the implementation right now?
4332016-04-28T19:02:09 *** grubles has joined #bitcoin-core-dev
4342016-04-28T19:02:27 <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.
4352016-04-28T19:02:29 <wumpus> last two items are done at least, transition to trusty and c++11 was succesful
4362016-04-28T19:02:50 <gmaxwell> \O/
4372016-04-28T19:02:52 <wumpus> kanzure: yes the name is who suggested it, Idon't know the context
4382016-04-28T19:02:52 <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/
4392016-04-28T19:02:58 <sdaftuar> kanzure: i'd be happy to review your notes
4402016-04-28T19:03:07 <kanzure> sdaftuar: cool, i will spam you with them
4412016-04-28T19:03:16 <cfields> jtimon: sorry, i got lost in the transition stuff
4422016-04-28T19:03:24 <wumpus> jtimon: oh maybe he's going to, but he had a lot on his hands
4432016-04-28T19:03:46 <jtimon> no hurry, just saying that I'm not working on that
4442016-04-28T19:04:01 <wumpus> okay :)
4452016-04-28T19:04:25 <wumpus> how is the review of segwit going?
4462016-04-28T19:04:34 <kanzure> sdaftuar: you have been spammed, thanks.
4472016-04-28T19:05:53 <morcos> wumpus: i'm feeling pretty good, but it's hard to tell who all has done deep commit by commit reviews
4482016-04-28T19:05:55 <kanzure> topic suggestion-- how to convince sipa to give more context about testing status of segwit
4492016-04-28T19:06:15 <sdaftuar> wumpus: i'm slowly making my way through
4502016-04-28T19:06:23 <wumpus> morcos: good to hear that you're making your way through
4512016-04-28T19:06:24 <kanzure> morcos: perhaps we should all post about our review status?
4522016-04-28T19:06:31 <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
4532016-04-28T19:06:49 <morcos> cfields: oh thats great!
4542016-04-28T19:07:00 <cfields> *segnet block with witness txs, ofc
4552016-04-28T19:07: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 ).
4562016-04-28T19:07:09 <morcos> time for someone else to get some segnet coins, i have too many
4572016-04-28T19:07:45 <sipa> i could list a few areas where i think mildly tricky things are done that warrant review
4582016-04-28T19:07:50 <kanzure> yes please.
4592016-04-28T19:08:50 <wumpus> #action (sipa) list a few areas where i think mildly tricky things are done that warrant review
4602016-04-28T19:08:55 <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
4612016-04-28T19:09:20 <sipa> good to know
4622016-04-28T19:09:32 <kanzure> signaturehash changes were specified by bip and one (trivial) review task is "confirm it follows the bip spec"
4632016-04-28T19:09:47 <morcos> sipa: harder b/c of me, not b/c the code is tricky looking
4642016-04-28T19:10:14 <instagibbs> morcos, maybe have people express review coverage with amount of certainty based on familiarity with the code
4652016-04-28T19:10:33 <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
4662016-04-28T19:10:52 <instagibbs> for me, review of wallet code was much easier than parsing the tree commitment stuff
4672016-04-28T19:11:02 <cfields> kanzure: some input from other projects (NicolasDorier *poke*) may be helpful there.
4682016-04-28T19:11:12 *** To7 has joined #bitcoin-core-dev
4692016-04-28T19:11:14 <morcos> instagibbs: i like that idea. not sure how easy it is to break up
4702016-04-28T19:11:37 <instagibbs> that said, I read *every* commit, and attempted best-effort understanding
4712016-04-28T19:11:37 <sipa> cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
4722016-04-28T19:11:43 *** BonyM has joined #bitcoin-core-dev
4732016-04-28T19:11:54 <morcos> ok got to run. overall, yay for c++11, yay for segwit!
4742016-04-28T19:11:54 <cfields> sipa: ah, right. ack.
4752016-04-28T19:11:55 *** NotAnNSAgent has quit IRC
4762016-04-28T19:12:14 *** NotAnNSAgent has joined #bitcoin-core-dev
4772016-04-28T19:12:17 <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.
4782016-04-28T19:12:36 *** kadoban has joined #bitcoin-core-dev
4792016-04-28T19:12:47 <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
4802016-04-28T19:13:21 <instagibbs> jtimon, which brings me to my point, aside from sipa and a few others, I doubt anyone can full utACK #7910
4812016-04-28T19:14:09 <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.
4822016-04-28T19:14:38 *** wallet421 has joined #bitcoin-core-dev
4832016-04-28T19:14:59 <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
4842016-04-28T19:15:03 <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?
4852016-04-28T19:15:23 <kanzure> sipa: i think that is a good idea. it gives us time to ACK various older commits.
4862016-04-28T19:15:31 <instagibbs> jtimon, seems wise, people have to self-select what they feel competent to review
4872016-04-28T19:15:35 *** wallet421 has quit IRC
4882016-04-28T19:16:00 <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
4892016-04-28T19:16:07 <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)
4902016-04-28T19:16:42 <kanzure> tree id similarity is a nice approach....
4912016-04-28T19:16:49 <kanzure> (git ls-tree and such)
4922016-04-28T19:17:18 <sipa> jtimon: i'll keep the section
4932016-04-28T19:17:25 <sdaftuar> sipa: some kind of warning before you squash/rebase would be helpful for me at least
4942016-04-28T19:17:44 <sdaftuar> sipa: but i like how you've done it so far
4952016-04-28T19:17:46 <kanzure> it would also be good if you could keep the original commits around on your git repo
4962016-04-28T19:17:52 <sipa> kanzure: of course
4972016-04-28T19:17:54 <jtimon> sipa: I see, so your question is more about squashing only once at the end, fine with me
4982016-04-28T19:17:59 <sipa> it needs to be verifiable
4992016-04-28T19:18:03 <kanzure> good, thanks.
5002016-04-28T19:18:25 <cfields> sipa: you can just push to a spare branch before final squash, then we can diff the two
5012016-04-28T19:18:42 <jonasschnelli> only add commits, once we have enough ACKS, hash the diff, rebase, check the hash of the diff and merge?
5022016-04-28T19:18:55 <sipa> jonasschnelli: indeed
5032016-04-28T19:20:06 <wumpus> ok next topic?
5042016-04-28T19:20:29 <wumpus> #topic status of the segwit BIPs
5052016-04-28T19:21:18 <wumpus> (gmaxwell)
5062016-04-28T19:21:29 <achow101> bip 144 needs to include the service bit stuff
5072016-04-28T19:22:23 <wumpus> everyone agree?
5082016-04-28T19:22:48 <sipa> ugh, that was never uodated
5092016-04-28T19:22:51 <sipa> yes, agree
5102016-04-28T19:23:15 <wumpus> #action bip 144 needs to include the service bit stuff
5112016-04-28T19:23:31 <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.
5122016-04-28T19:23:50 <instagibbs> roasbeef*
5132016-04-28T19:24:00 <petertodd> just noticed someone has a python-bitcoinlib segwit branch too
5142016-04-28T19:24:07 <achow101> armory does as well
5152016-04-28T19:24:27 <petertodd> (sorry, just got in)
5162016-04-28T19:24:53 *** matsjj has joined #bitcoin-core-dev
5172016-04-28T19:24:59 <wumpus> petertodd: just in time for the python-bitcoinlib segwit branch!
5182016-04-28T19:25:31 <petertodd> wumpus: ha yeah - no credit to me though :)
5192016-04-28T19:26:20 <wumpus> #action (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
5202016-04-28T19:26:46 <sipa> we have gotten some comments from a few people and making small clarifications frequently
5212016-04-28T19:26:55 <sipa> including from tadge
5222016-04-28T19:27:29 <sipa> i'm surprised nobody commented about the service bit
5232016-04-28T19:27:52 <achow101> sipa: I think I brought it up a couple of weeks ago but didn't follow up on it
5242016-04-28T19:28:02 <sipa> achow101: sorry then!
5252016-04-28T19:29:22 <instagibbs> I can verify 141 and 143 match up
5262016-04-28T19:30:33 <wumpus> great
5272016-04-28T19:31:04 *** laurentmt has joined #bitcoin-core-dev
5282016-04-28T19:31:09 *** laurentmt has quit IRC
5292016-04-28T19:32:15 <sipa> small update: the reviewer that btcdrak contacted about ctaes wrote a report
5302016-04-28T19:32:33 <jonasschnelli> sipa: the tor lead dev?
5312016-04-28T19:32:51 <sipa> jonasschnelli: no, someone mathhew green recommemded
5322016-04-28T19:33:04 <sipa> he formally proved that some parts were correct, and analyzed the condtant timeness
5332016-04-28T19:33:07 <jonasschnelli> Okay. Good. What was the result?
5342016-04-28T19:33:09 <sipa> i can share the reoort
5352016-04-28T19:33:11 <petertodd> sipa: +1
5362016-04-28T19:33:16 <sipa> a+ :)
5372016-04-28T19:33:24 <jonasschnelli> sipa: Can you add it on your ctaes repository?
5382016-04-28T19:33:27 <wumpus> awesome!
5392016-04-28T19:33:49 <cfields> sipa: nice!
5402016-04-28T19:34:03 *** gevs has quit IRC
5412016-04-28T19:35:16 <sipa> any more topics? i'll be off otherwise
5422016-04-28T19:35:30 <jonasschnelli> RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
5432016-04-28T19:35:59 <petertodd> jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
5442016-04-28T19:36:00 <jl2012> bringing segwit testing to testnet?
5452016-04-28T19:36:09 <gmaxwell> the former, I think. It's incorrect to say non-RBF is non-replacable; they're just somewhat less replacable.
5462016-04-28T19:36:55 <wumpus> agree with gmaxwell
5472016-04-28T19:37:13 <jonasschnelli> Okay. I agree as well. Will continue with this term.
5482016-04-28T19:37:16 <instagibbs> 'mempool-replaceable' ?
5492016-04-28T19:37:26 <petertodd> doublespends happen all the time, and only a small subset of them are opt-in RBF txs
5502016-04-28T19:37:42 <wumpus> but RBF transactions the user can easily replace themselves
5512016-04-28T19:37:42 <jl2012> sipa: are we ready to define the testnet BIP9 parameter for segwit?
5522016-04-28T19:37:47 <wumpus> that should be the focus imo
5532016-04-28T19:38:06 <wumpus> what the user can do with it
5542016-04-28T19:38:10 <jonasschnelli> instagibbs: I was also thinking about that. But does the normal bitcoin-qt user really knows what the mempool is?
5552016-04-28T19:38:13 <jtimon> "standard-policy-0.12-replaceable"?
5562016-04-28T19:38:26 <jonasschnelli> :}
5572016-04-28T19:38:40 <petertodd> jtimon: all the user's node knowns is they think it's replacable, so the 0.12 is implicit :)
5582016-04-28T19:38:40 <jonasschnelli> "standard-policy-0.12-BIP125-replaceable"
5592016-04-28T19:38:50 *** chris2000 has quit IRC
5602016-04-28T19:39:13 <wumpus> yes the 0.12 is implicit, the BIP125 part makes sense
5612016-04-28T19:39:34 <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
5622016-04-28T19:39:36 <petertodd> don't we already have a bip125-replacable or similar name used in the RPC anyway?
5632016-04-28T19:39:54 <jonasschnelli> petertodd: Yes. Listtransaction
5642016-04-28T19:40:03 <wumpus> yes entry.push_back(Pair("bip125-replaceable", rbfStatus));
5652016-04-28T19:40:21 <jtimon> ack bip125-replaceable
5662016-04-28T19:40:26 <jonasschnelli> Also I think someone should refactor the RBF BIP125 rules to the new rbf.cpp
5672016-04-28T19:40:31 <petertodd> jtimon: you can also replace txs by flooding mempools and getting them kicked out :)
5682016-04-28T19:40:40 <jonasschnelli> The bumpfee or feealter command could than re-check the validity
5692016-04-28T19:40:42 *** Michail1 has joined #bitcoin-core-dev
5702016-04-28T19:40:52 <jonasschnelli> s/re-check/pre-check
5712016-04-28T19:41:37 <jonasschnelli> In the GUI we should probably just use the term "replaceable".
5722016-04-28T19:42:22 <jtimon> then we have the same problem I think
5732016-04-28T19:42:24 <petertodd> jonasschnelli: "easily replacable"
5742016-04-28T19:42:27 <jtimon> opt-in-repleaceable ?
5752016-04-28T19:42:38 <petertodd> jonasschnelli: or heck, "trivially replacable"
5762016-04-28T19:42:45 <paveljanik> "updatable"?
5772016-04-28T19:43:03 <luke-jr> "replacement-requested"
5782016-04-28T19:43:04 <jonasschnelli> of "signs replicability"?
5792016-04-28T19:43:21 <petertodd> paveljanik: eh, changing the name to something other than replacable would invite trolling possibly
5802016-04-28T19:43:39 <paveljanik> replacability signalled ;-)
5812016-04-28T19:43:48 <jonasschnelli> replacability signalled: +1
5822016-04-28T19:43:57 <wumpus> yes I think whatever the name is it should contain 'replace', otherwise it's too confusing, introducing completely new terminology
5832016-04-28T19:44:02 <petertodd> wumpus: +1
5842016-04-28T19:44:05 *** muuqwaul has joined #bitcoin-core-dev
5852016-04-28T19:44:06 <jonasschnelli> Indeed
5862016-04-28T19:44:12 <wumpus> replaceability signalled sounds good to me
5872016-04-28T19:44:22 <petertodd> sure, why not
5882016-04-28T19:44:36 <jonasschnelli> ack
5892016-04-28T19:44:38 <jtimon> "replace explicitly allowed"?
5902016-04-28T19:44:41 <sdaftuar> fee-replaceable ?
5912016-04-28T19:44:56 <jonasschnelli> sdaftuar: but it could also add a output
5922016-04-28T19:44:57 <jtimon> I mean, "replacability signalled" is good enough for me
5932016-04-28T19:45:28 <jonasschnelli> sdaftuar: but right. You mean replaceable by fee
5942016-04-28T19:45:37 <sdaftuar> yeah, you can replace it if you up the fee
5952016-04-28T19:45:58 <jonasschnelli> "fee-replacability signalled"?
5962016-04-28T19:46:06 <petertodd> jonasschnelli: which is tricky, because any low fee tx is in practice replacable by fee regardless of whether bip125 is used or not
5972016-04-28T19:46:20 <sdaftuar> but not by your wallet
5982016-04-28T19:46:38 <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
5992016-04-28T19:46:43 *** gevs has joined #bitcoin-core-dev
6002016-04-28T19:46:44 *** gevs has joined #bitcoin-core-dev
6012016-04-28T19:46:45 <sdaftuar> +1
6022016-04-28T19:46:46 <jonasschnelli> Sure. But the term would also be for attributing incoming payment.
6032016-04-28T19:46:47 <petertodd> oh, key question: are we going to show this for all txs, or just txs sent by the user?
6042016-04-28T19:46:54 <paveljanik> sdaftuar, depends on the wallet IMO
6052016-04-28T19:46:56 <jtimon> petertodd: exactly, for all we know, miners could replace by hash alphabetic order rather than fees
6062016-04-28T19:47:01 <cfields> sdaftuar: i like that, but it describes the mechanics more than the intent.
6072016-04-28T19:47:07 <jonasschnelli> petertodd: incoming and outdoing.
6082016-04-28T19:47:25 <petertodd> jonasschnelli: see, if it was just outgoing, this conversation would be a lot simpler :)
6092016-04-28T19:48:11 <wumpus> replacability signalled is fine, let's move on
6102016-04-28T19:48:15 <jonasschnelli> incoming tx: "replacability signalled", create tx: "[ ] signall replacability"
6112016-04-28T19:48:18 <jonasschnelli> ack.
6122016-04-28T19:48:21 <jtimon> what was wrong about "Opted in to replacement" or something along those lines?
6132016-04-28T19:48:23 <wumpus> any other topics?
6142016-04-28T19:48:44 <jtimon> yeah, nv, "replacability signalled" does it
6152016-04-28T19:48:59 <jtimon> s/nv/never mind
6162016-04-28T19:49:01 <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.
6172016-04-28T19:49:11 <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.
6182016-04-28T19:49:25 <paveljanik> press kit? ;-)
6192016-04-28T19:49:30 <petertodd> paveljanik: +1
6202016-04-28T19:49:44 <jonasschnelli> We probably don't care. But out userbase does a lot
6212016-04-28T19:49:46 <petertodd> paveljanik: or maybe call it "media kit" to shift focus to all media in general
6222016-04-28T19:49:50 <jonasschnelli> *our
6232016-04-28T19:49:59 <btcdrak> jonasschnelli: a press kit would be a good idea
6242016-04-28T19:50:06 <wumpus> we don't have that, but if anyone wants to make it and collect some things why not
6252016-04-28T19:50:54 <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.
6262016-04-28T19:50:56 <btcdrak> jonaschnelli: ideally we could store that in a "media kit" repository.
6272016-04-28T19:51:16 <jonasschnelli> I think it should be a subarea of the website
6282016-04-28T19:51:37 <petertodd> jonasschnelli: that makes sense
6292016-04-28T19:51:46 <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
6302016-04-28T19:52:21 <jonasschnelli> Agree.
6312016-04-28T19:52:26 <sipa> wumpus: they're very common among altcoins though :p
6322016-04-28T19:52:27 <cfields> wumpus: for open-source, they almost always accompany a licensing policy
6332016-04-28T19:52:41 <cfields> (lived through that hell for a while in a past life)
6342016-04-28T19:52:50 <wumpus> cfields: yes, as for firefox
6352016-04-28T19:52:54 <cfields> right
6362016-04-28T19:53:38 <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.
6372016-04-28T19:54:08 <cfields> i suppose that was the idea, though
6382016-04-28T19:54:08 <wumpus> right
6392016-04-28T19:54:10 <jonasschnelli> Yes. There is even no clear logo that Bitcoin Core uses/represents.
6402016-04-28T19:54:15 <warren> "\nExamples:\n"
6412016-04-28T19:54:17 <warren> + HelpExampleCli("getnewaddress", "")
6422016-04-28T19:54:21 <warren> + HelpExampleRpc("getnewaddress", "")
6432016-04-28T19:54:23 <warren> Any idea why this has both, and they're identical?
6442016-04-28T19:54:25 <jonasschnelli> warren: dumpprivatekey
6452016-04-28T19:54:39 <wumpus> warren: we're in the middle of a meeting
6462016-04-28T19:54:45 <warren> oops sorry!
6472016-04-28T19:54:45 <wumpus> well, at the end
6482016-04-28T19:55:20 <wumpus> I think we're done
6492016-04-28T19:55:34 <jonasschnelli> \ö/
6502016-04-28T19:55:37 <wumpus> #endmeeting
6512016-04-28T19:55:37 <lightningbot> Meeting ended Thu Apr 28 19:55:37 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6522016-04-28T19:55:37 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.html
6532016-04-28T19:55:37 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.txt
6542016-04-28T19:55:37 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.log.html
6552016-04-28T19:55:50 <warren> jonasschnelli: ok, not understanding what you mean
6562016-04-28T19:55:55 <wumpus> warren: we have cli and rpc examples for all the help items
6572016-04-28T19:56:06 <warren> why are they both provided when identical?
6582016-04-28T19:56:08 <wumpus> warren: just do 'help getnewaddress' to see what the output is
6592016-04-28T19:56:17 <jonasschnelli> warren: nm. RPC does form a different help line then cli
6602016-04-28T19:56:28 <wumpus> they aren't identical
6612016-04-28T19:56:46 <wumpus> the result is different, they call different functions that have different output, just happens to be with the same arguments
6622016-04-28T19:56:55 <warren> oh ok, thanks
6632016-04-28T19:57:25 <wumpus> as said, just check 'bitcoin-cli help getnewaddress` and you'll see
6642016-04-28T20:05:11 *** earlest has joined #bitcoin-core-dev
6652016-04-28T20:05:48 *** cryptapus has quit IRC
6662016-04-28T20:07:46 <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
6672016-04-28T20:08:04 *** muuqwaul has quit IRC
6682016-04-28T20:13:59 *** laurentmt has joined #bitcoin-core-dev
6692016-04-28T20:14:35 *** cjcj has quit IRC
6702016-04-28T20:19:45 *** laurentmt has quit IRC
6712016-04-28T20:50:54 *** ThomasV has joined #bitcoin-core-dev
6722016-04-28T20:52:04 *** guest78678 has joined #bitcoin-core-dev
6732016-04-28T20:53:05 <guest78678> why are we keeping AcceptToMemoryPoolWorker in main?
6742016-04-28T20:55:12 *** xiangfu has joined #bitcoin-core-dev
6752016-04-28T20:57:07 *** guest78678 has quit IRC
6762016-04-28T21:10:58 *** jannes has quit IRC
6772016-04-28T21:15:35 *** ThomasV has quit IRC
6782016-04-28T21:15:59 *** cryptapus_afk is now known as cryptapus
6792016-04-28T21:24:11 <instagibbs> did someone volunteer to fix up bip144? missed the last part of meeting
6802016-04-28T21:36:38 <btcdrak> instagibbs: it was you iirc.
6812016-04-28T21:37:37 *** treehug88 has quit IRC
6822016-04-28T21:39:17 <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
6832016-04-28T21:39:48 *** zooko has joined #bitcoin-core-dev
6842016-04-28T21:40:03 <btcdrak> achow101: I was teasing instagibbs. Go ahead.
6852016-04-28T21:41:07 *** xiangfu has quit IRC
6862016-04-28T21:41:26 *** frankenmint has joined #bitcoin-core-dev
6872016-04-28T21:42:58 * instagibbs shakes fist at btcdrak
6882016-04-28T21:43:05 <instagibbs> achow101, good, go for it
6892016-04-28T21:43:11 <instagibbs> wanted to make sure *someone* was doing it
6902016-04-28T21:43:19 <instagibbs> I can review after the fact
6912016-04-28T21:43:34 <achow101> which bit is it?
6922016-04-28T21:44:15 <instagibbs> not sure, I'd find out, but have family stuff to do
6932016-04-28T21:44:23 <instagibbs> I think the service hex is "d"
6942016-04-28T21:44:38 <instagibbs> bbl if you still havent figured it out
6952016-04-28T21:46:03 <achow101> found it
6962016-04-28T21:50:35 *** grassass has quit IRC
6972016-04-28T21:53:17 *** zooko has quit IRC
6982016-04-28T21:53:47 <achow101> done https://github.com/bitcoin/bips/pull/380
6992016-04-28T22:03:28 *** lecusemble has quit IRC
7002016-04-28T22:04:55 *** Alopex has quit IRC
7012016-04-28T22:05:07 *** lecusemble has joined #bitcoin-core-dev
7022016-04-28T22:07:03 <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.
7032016-04-28T22:10:27 <GitHub23> [bitcoin] wtogami opened pull request #7968: doc: Fedora build requirements (master...fedora_build_readme) https://github.com/bitcoin/bitcoin/pull/7968
7042016-04-28T22:13:28 <achow101> btcdrak: I'd let sipa do that
7052016-04-28T22:16:06 *** Alopex has joined #bitcoin-core-dev
7062016-04-28T22:32:28 *** Chris_Stewart_5 has quit IRC
7072016-04-28T22:34:35 *** cryptapus is now known as cryptapus_afk
7082016-04-28T22:38:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
7092016-04-28T22:47:24 *** Chris_Stewart_5 has quit IRC
7102016-04-28T22:53:01 *** Alopex has quit IRC
7112016-04-28T22:53:10 *** laurentmt has joined #bitcoin-core-dev
7122016-04-28T22:54:00 *** laurentmt has quit IRC
7132016-04-28T22:54:07 *** Alopex has joined #bitcoin-core-dev
7142016-04-28T22:57:03 *** AaronvanW has quit IRC
7152016-04-28T23:24:50 *** Guyver2 has quit IRC
7162016-04-28T23:44:36 *** belcher has quit IRC