12016-06-06T00:00:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
22016-06-06T00:03:36 *** jarret_ has joined #bitcoin-core-dev
32016-06-06T00:03:49 *** jarret has quit IRC
42016-06-06T00:21:16 *** Ylbam has quit IRC
52016-06-06T00:46:23 *** TomMc has quit IRC
62016-06-06T01:15:56 <GitHub145> [bitcoin] jmcorgan closed pull request #8148: Backport leveldb build integration to 0.12 (0.12...0.12) https://github.com/bitcoin/bitcoin/pull/8148
72016-06-06T01:26:02 *** Alopex has quit IRC
82016-06-06T01:27:07 *** Alopex has joined #bitcoin-core-dev
92016-06-06T01:30:24 *** TomMc has joined #bitcoin-core-dev
102016-06-06T01:35:12 *** dermoth has quit IRC
112016-06-06T01:36:02 *** dermoth has joined #bitcoin-core-dev
122016-06-06T01:45:58 *** xiangfu has joined #bitcoin-core-dev
132016-06-06T01:54:54 *** sanada has quit IRC
142016-06-06T01:59:57 *** CubicEarth has joined #bitcoin-core-dev
152016-06-06T02:41:06 *** CubicEarth has quit IRC
162016-06-06T02:43:41 *** CubicEarth has joined #bitcoin-core-dev
172016-06-06T02:51:37 *** TomMc has quit IRC
182016-06-06T02:52:38 *** fanquake has joined #bitcoin-core-dev
192016-06-06T03:01:44 *** fanquake has quit IRC
202016-06-06T03:24:37 *** achow101 has quit IRC
212016-06-06T03:26:02 *** Alopex has quit IRC
222016-06-06T03:27:07 *** Alopex has joined #bitcoin-core-dev
232016-06-06T03:45:39 *** Chris_Stewart_5 has quit IRC
242016-06-06T03:46:35 *** grassass has quit IRC
252016-06-06T03:54:05 *** TomMc has joined #bitcoin-core-dev
262016-06-06T04:07:13 *** sanada has joined #bitcoin-core-dev
272016-06-06T04:12:42 *** TomMc has quit IRC
282016-06-06T04:14:47 *** PaulCape_ has joined #bitcoin-core-dev
292016-06-06T04:16:11 *** CubicEarth has quit IRC
302016-06-06T04:17:52 *** PaulCapestany has quit IRC
312016-06-06T04:32:46 *** challisto has quit IRC
322016-06-06T04:41:28 *** CubicEarth has joined #bitcoin-core-dev
332016-06-06T04:42:50 <phantomcircuit> wumpus, fyi the two prs for wallet stuff dont merge cleanly against each other because of a trivial conflict
342016-06-06T04:43:13 <phantomcircuit> if one gets merged i will rebase the other and/or the merge can fix it
352016-06-06T05:04:19 *** CubicEarth has quit IRC
362016-06-06T05:07:25 *** gevs has quit IRC
372016-06-06T05:08:01 *** kadoban has joined #bitcoin-core-dev
382016-06-06T05:15:25 *** netzin has joined #bitcoin-core-dev
392016-06-06T05:16:56 *** jtimon has quit IRC
402016-06-06T05:19:24 *** paveljanik has quit IRC
412016-06-06T05:19:28 *** frankenmint has joined #bitcoin-core-dev
422016-06-06T05:20:00 *** gevs has joined #bitcoin-core-dev
432016-06-06T05:20:00 *** gevs has joined #bitcoin-core-dev
442016-06-06T05:49:39 *** supasonic has quit IRC
452016-06-06T05:50:07 *** supasonic has joined #bitcoin-core-dev
462016-06-06T05:52:01 *** Alopex has quit IRC
472016-06-06T05:53:07 *** Alopex has joined #bitcoin-core-dev
482016-06-06T05:54:23 *** kadoban has quit IRC
492016-06-06T05:55:16 *** supasonic has quit IRC
502016-06-06T05:57:50 *** netzin has quit IRC
512016-06-06T05:57:58 *** CubicEarth has joined #bitcoin-core-dev
522016-06-06T06:13:01 *** Alopex has quit IRC
532016-06-06T06:14:06 *** Alopex has joined #bitcoin-core-dev
542016-06-06T06:30:39 *** jarret_ has quit IRC
552016-06-06T06:30:57 *** jarret_ has joined #bitcoin-core-dev
562016-06-06T06:37:01 <wumpus> damnit, trying to copy the transifex resource for 0.13 but looks like my script to clone transifex resources no longer works, transifex API PUTs take forever now
572016-06-06T06:38:36 *** molz has joined #bitcoin-core-dev
582016-06-06T06:41:34 *** molly has quit IRC
592016-06-06T06:41:43 <wumpus> oh nm it works, just slow
602016-06-06T06:41:59 <wumpus> and not for south african, somehow
612016-06-06T06:42:34 *** MarcoFalke has joined #bitcoin-core-dev
622016-06-06T06:46:20 *** Ylbam has joined #bitcoin-core-dev
632016-06-06T06:47:10 *** frankenmint has quit IRC
642016-06-06T06:50:24 *** BashCo_ has quit IRC
652016-06-06T07:05:21 *** trippysalmon has joined #bitcoin-core-dev
662016-06-06T07:11:25 *** CubicEarth has quit IRC
672016-06-06T07:11:42 *** CubicEarth has joined #bitcoin-core-dev
682016-06-06T07:16:36 *** BashCo has joined #bitcoin-core-dev
692016-06-06T07:20:30 *** ozanyurt has joined #bitcoin-core-dev
702016-06-06T07:33:03 *** calibre720 has quit IRC
712016-06-06T07:53:26 *** Giszmo has quit IRC
722016-06-06T07:58:36 *** AaronvanW has joined #bitcoin-core-dev
732016-06-06T07:58:37 *** AaronvanW has quit IRC
742016-06-06T07:58:37 *** AaronvanW has joined #bitcoin-core-dev
752016-06-06T08:07:36 *** jarret_ has quit IRC
762016-06-06T08:09:41 *** frankenmint has joined #bitcoin-core-dev
772016-06-06T08:23:01 *** jannes has joined #bitcoin-core-dev
782016-06-06T08:23:44 *** G1lius has joined #bitcoin-core-dev
792016-06-06T08:34:54 <GitHub130> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/e6b141acf9dcc0a12f49d53c0bb8a892bae72217
802016-06-06T08:34:54 <GitHub130> bitcoin/master e6b141a Wladimir J. van der Laan: qt: translation strings update
812016-06-06T09:17:35 *** Guyver2 has joined #bitcoin-core-dev
822016-06-06T09:33:19 *** molly has joined #bitcoin-core-dev
832016-06-06T09:36:04 *** molz has quit IRC
842016-06-06T09:49:31 *** CubicEarth has quit IRC
852016-06-06T09:54:09 *** Ginnarr has joined #bitcoin-core-dev
862016-06-06T10:09:16 *** ozanyurt_ has joined #bitcoin-core-dev
872016-06-06T10:10:24 *** ozanyurt has quit IRC
882016-06-06T10:28:07 *** ozanyurt_ has quit IRC
892016-06-06T10:28:44 *** ozanyurt has joined #bitcoin-core-dev
902016-06-06T10:29:23 *** MarcoFalke has left #bitcoin-core-dev
912016-06-06T10:32:29 *** xiangfu has quit IRC
922016-06-06T10:47:00 *** gevs_ has joined #bitcoin-core-dev
932016-06-06T10:48:06 *** gevs has quit IRC
942016-06-06T11:32:45 *** jtimon has joined #bitcoin-core-dev
952016-06-06T11:43:36 *** Ginnarr has quit IRC
962016-06-06T11:49:01 *** achow101 has joined #bitcoin-core-dev
972016-06-06T12:11:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
982016-06-06T12:24:23 *** jarret has joined #bitcoin-core-dev
992016-06-06T12:59:40 <GitHub71> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e6b141acf9dc...243ac0c75b1b
1002016-06-06T12:59:40 <GitHub71> bitcoin/master 9dfaa1c Patrick Strateman: Improve CWallet API with new AccountMove function.
1012016-06-06T12:59:41 <GitHub71> bitcoin/master 243ac0c Wladimir J. van der Laan: Merge #8137: Improve CWallet API with new AccountMove function....
1022016-06-06T12:59:50 <GitHub112> [bitcoin] laanwj closed pull request #8137: Improve CWallet API with new AccountMove function. (master...2016-06-02-cwallet-accountmove) https://github.com/bitcoin/bitcoin/pull/8137
1032016-06-06T13:06:14 <GitHub174> [bitcoin] sipa opened pull request #8149: Segregated witness rebased (master...segwit-master2) https://github.com/bitcoin/bitcoin/pull/8149
1042016-06-06T13:07:40 *** paveljanik has joined #bitcoin-core-dev
1052016-06-06T13:12:42 *** gevs_ has quit IRC
1062016-06-06T13:13:03 *** gevs has joined #bitcoin-core-dev
1072016-06-06T13:13:53 <sipa_> #8149 is 25% consensus/p2p/node changes, 10% wallet/signing changes, and 65% tests
1082016-06-06T13:14:04 <sipa_> (the tests mostly due to sdaftuar)
1092016-06-06T13:15:27 <sipa_> well, mostly is exaggerated, but more than half of it is from his p2p test
1102016-06-06T13:15:54 * sipa_ wishes that git/github had a way to organize commits in a PR hierarchically
1112016-06-06T13:22:47 <instagibbs> yes, those tests are very comprehensive, thanks sdaftuar :)
1122016-06-06T13:22:55 *** helo_ is now known as helo
1132016-06-06T13:36:44 <kanzure> sipa_: could you add some text to the top-level comment in pull request 7910 to refer to 8149 (otherwise folks will have to read all the way to the bottom to learn about 8149)
1142016-06-06T13:38:05 *** MarcoFalke has joined #bitcoin-core-dev
1152016-06-06T13:38:18 *** TomMc has joined #bitcoin-core-dev
1162016-06-06T13:39:10 *** zooko has joined #bitcoin-core-dev
1172016-06-06T13:39:55 <sipa_> kanzure: done
1182016-06-06T13:44:36 *** zooko has quit IRC
1192016-06-06T13:45:59 <GitHub6> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/243ac0c75b1b...6b781df74fc2
1202016-06-06T13:45:59 <GitHub6> bitcoin/master f0fdda0 Kaz Wesley: IsInitialBlockDownload: usually avoid locking...
1212016-06-06T13:46:00 <GitHub6> bitcoin/master 6b781df Wladimir J. van der Laan: Merge #8007: Minor locking improvements...
1222016-06-06T13:46:07 <GitHub99> [bitcoin] laanwj closed pull request #8007: Minor locking improvements (master...locknits) https://github.com/bitcoin/bitcoin/pull/8007
1232016-06-06T13:46:31 <cfields_> luke-jr: ping. I'm not seeing your "-dirty" behavior
1242016-06-06T13:46:47 <MarcoFalke> sipa_: How do you plan to handle "segnet is not intended to be merged into Core"
1252016-06-06T13:47:13 <MarcoFalke> is it going to be merged to result in the same tree hash?
1262016-06-06T13:47:39 <sipa_> MarcoFalke: in 7910 i will add a commit to remove it; in 8149 is will be removed from history
1272016-06-06T13:48:40 <sipa_> i'll keep updating both PRs now, as i don't expect many changes anymore
1282016-06-06T13:49:02 <kanzure> i wonder if git can revert a (given) patch post-rebase
1292016-06-06T13:49:02 <sipa_> but there are still a few (GBT, dns seeds, segnet, ...)
1302016-06-06T13:49:28 <sipa_> kanzure: pretty sure it can, if it doesn't conflict
1312016-06-06T13:50:13 <kanzure> alright then the check is "post-rebase, revert the remove-segnet patch, then check to see if the tree matches" (or you can compare 7910 latest tree hash with 8149 latest tree hash)
1322016-06-06T13:50:37 *** gevs has quit IRC
1332016-06-06T13:50:49 <sipa_> i'll just keep both in sync
1342016-06-06T13:50:57 <MarcoFalke> Also, I think GitHub orders by commit date and not author date.
1352016-06-06T13:51:13 <MarcoFalke> If that is something to care about
1362016-06-06T13:51:27 <sipa_> MarcoFalke: that's why i provide my own list of commits...
1372016-06-06T13:51:38 <sipa_> i want them to be dependency-ordered, not time
1382016-06-06T13:52:47 <sdaftuar> sipa_: what's your preference for which PR we should post additional review comments?
1392016-06-06T13:53:41 <sipa_> sdaftuar: 7910
1402016-06-06T13:53:42 <MarcoFalke> Better keep it in 7910, so it is not all over the place?
1412016-06-06T13:53:57 <sdaftuar> sounds good
1422016-06-06T14:03:27 <instagibbs> might want to note that directly in both PRs
1432016-06-06T14:07:59 <MarcoFalke> wumpus: I am happy to fix that as well in the pull ( https://github.com/bitcoin/bitcoin/pull/8144#discussion-diff-65889382 ) but I'd like to know if the current wording is suitable, first.
1442016-06-06T14:08:37 <MarcoFalke> For the general direction, I agree with what sipa commented on the pull. We should probably rework the wallet fee behavior... But I don't see that happen in 0.13.0
1452016-06-06T14:09:03 <wumpus> yes, the wording sounds good to me
1462016-06-06T14:09:27 <wumpus> and indeed an option for confirm target would be nice too
1472016-06-06T14:09:54 <wumpus> but that's something else, no need to do it there
1482016-06-06T14:10:04 *** ghtdak has quit IRC
1492016-06-06T14:11:01 *** ghtdak has joined #bitcoin-core-dev
1502016-06-06T14:11:28 <wumpus> I think being consistent with amounts is pretty important, there is already one place where satoshis values leaked in the RPC API (the fee delta in mining.cpp), we were too late with changing there as that version was already deployed
1512016-06-06T14:11:54 <MarcoFalke> Making it confirm target would change the behavior and users seem to be very sensitive to such wallet behavior changes
1522016-06-06T14:11:59 <MarcoFalke> as we noticed in 0.12
1532016-06-06T14:12:02 <helo> sorry to bikeshed... i know a confrimation target can't be guaranteed, but can it have confidence intervals to temper expectations?
1542016-06-06T14:12:23 <wumpus> don't we already have a confirm target?
1552016-06-06T14:12:30 <wumpus> this would just override the global steting
1562016-06-06T14:12:35 <MarcoFalke> not for fundrawtx?
1572016-06-06T14:12:45 <wumpus> ok, then only use it when the option is specified
1582016-06-06T14:13:02 <wumpus> I assumed it'd just use the global default confirmtarget unles specified otherwise
1592016-06-06T14:13:20 <MarcoFalke> And if the users didn't set anything, it will also happen to "fall back" to txconfirmtarget
1602016-06-06T14:13:28 <MarcoFalke> jup
1612016-06-06T14:13:30 <wumpus> that's what I mean
1622016-06-06T14:13:33 *** Inaltoasinistra has quit IRC
1632016-06-06T14:14:17 <wumpus> helo: if you find a way to compute those, sure
1642016-06-06T14:14:43 *** Inaltoasinistra has joined #bitcoin-core-dev
1652016-06-06T14:15:45 <helo> i'll give it a shot, we'll see
1662016-06-06T14:17:19 *** ozanyurt has quit IRC
1672016-06-06T14:17:30 <sipa_> helo: it aims for 95% confidence, iirc
1682016-06-06T14:17:47 <phantomcircuit> wumpus, rebased #8142
1692016-06-06T14:17:58 <MarcoFalke> based on the observations from the past
1702016-06-06T14:18:00 <wumpus> phantomcircuit: thanks
1712016-06-06T14:18:14 <MarcoFalke> But I don't think you can figure out confidence intervals for the future
1722016-06-06T14:18:26 <sipa_> MarcoFalke: of course
1732016-06-06T14:18:30 <helo> yeah, you can't... just bayesian i'd assum
1742016-06-06T14:19:55 <MarcoFalke> Yet another 32-bit 64-bit issue...
1752016-06-06T14:20:12 <MarcoFalke> Can we forbid floating point multiplication for CAmount?
1762016-06-06T14:20:52 <sipa_> MarcoFalke: where?
1772016-06-06T14:20:56 <MarcoFalke> In the tests
1782016-06-06T14:21:03 *** ozanyurt has joined #bitcoin-core-dev
1792016-06-06T14:21:15 <MarcoFalke> behavior is not the same on 32bit arch and 64
1802016-06-06T14:22:02 <wumpus> floating point for CAmounts? heresy!
1812016-06-06T14:22:10 <MarcoFalke> .6 * 100000 sat will give 59999 sat on 32bit under some circumstances
1822016-06-06T14:23:01 <wumpus> (and if you do you at least use correct rounding instead of truncation, but please don't use floating point for monetary amounts)
1832016-06-06T14:23:16 <MarcoFalke> Haven't yet figured out why it is working right now, but I was doing some refactor and triggered it.
1842016-06-06T14:29:01 <GitHub154> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6b781df74fc2...52c3f348bec3
1852016-06-06T14:29:01 <GitHub154> bitcoin/master 152ab23 Patrick Strateman: Improve CWallet API with new GetAccountPubkey function....
1862016-06-06T14:29:02 <GitHub154> bitcoin/master 52c3f34 Wladimir J. van der Laan: Merge #8142: Improve CWallet API with new GetAccountPubkey function....
1872016-06-06T14:29:11 <GitHub33> [bitcoin] laanwj closed pull request #8142: Improve CWallet API with new GetAccountPubkey function. (master...2016-06-02-cwallet-getaccountpubkey) https://github.com/bitcoin/bitcoin/pull/8142
1882016-06-06T14:29:19 *** Giszmo has joined #bitcoin-core-dev
1892016-06-06T14:38:21 *** cryptapus_afk is now known as cryptapus
1902016-06-06T14:40:48 <sipa_> i'd like to see some P2P tests for the eviction logic being touched in #8084 etc
1912016-06-06T14:41:02 <sipa_> but i don't know how to do that easily, as you'd need to spoof ip addresses
1922016-06-06T14:49:38 <kanzure> maybe te network refactor stuff could make that easier?
1932016-06-06T14:49:41 <kanzure> *the network
1942016-06-06T14:51:25 <sipa_> i expect it to, indeed
1952016-06-06T14:51:27 *** Chris_Stewart_5 has quit IRC
1962016-06-06T14:56:49 <luke-jr> cfields_: pong
1972016-06-06T15:07:54 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1982016-06-06T15:25:24 *** ozanyurt has quit IRC
1992016-06-06T15:30:59 *** ozanyurt has joined #bitcoin-core-dev
2002016-06-06T15:31:08 <GitHub72> [bitcoin] MarcoFalke opened pull request #8151: [init] Make feefilter option debug option (master...Mf1606-feefilterDebug) https://github.com/bitcoin/bitcoin/pull/8151
2012016-06-06T15:31:16 <MarcoFalke> wumpus, I think the issue is "JSONRPC error: Expected type number for feeRate, got string"
2022016-06-06T15:32:29 <MarcoFalke> ups
2032016-06-06T15:32:35 <MarcoFalke> forget what I said
2042016-06-06T15:33:06 *** hello_ has joined #bitcoin-core-dev
2052016-06-06T15:33:57 <hello_> Could someone explain the most recent issue raised on github ""Tell other nodes to filter invs to us by our mempool min fee" message is too technical"
2062016-06-06T15:34:30 <hello_> What is "invs" ... and what is the context here?
2072016-06-06T15:42:50 <sipa_> helo: if you need to ask what invs are, then it's an indication that the messages is indeed too technical
2082016-06-06T15:42:57 <sipa_> and that is the issue
2092016-06-06T15:43:20 <gmaxwell> it's not even a setting an ordinary user should ever touch.
2102016-06-06T15:43:30 <gmaxwell> -makemynodeworkworse
2112016-06-06T15:43:57 <instagibbs> jl2012, have you adapted the BIP/PR for relaxing witness program size yet?
2122016-06-06T15:44:11 <sipa_> instagibbs: yes, it's already included
2132016-06-06T15:44:16 <sipa_> (to length 40)
2142016-06-06T15:46:05 <instagibbs> ah thanks
2152016-06-06T15:47:02 <hello_> Well Im trying to contribute to bitcoin... So I would be happy if you could just give a line of explanation. :) Cheers..
2162016-06-06T15:47:43 <hello_> sipa_: I already understand about 50% of the software so ....
2172016-06-06T15:48:51 <sipa_> hello_: i'll gladly explain things, but i don't think this is the place to explain the basic p2p protocol :)
2182016-06-06T15:49:24 <MarcoFalke> hello_: There is a bitcoin wiki with the basic description
2192016-06-06T15:50:48 <sipa_> hello_: https://bitcoin.org/en/developer-guide#transaction-broadcasting for explanation of the transaction relay protocol
2202016-06-06T15:51:07 <sipa_> hello_: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki for feefilter
2212016-06-06T15:53:10 *** frankenmint has quit IRC
2222016-06-06T15:54:03 <hello_> Thank you a lot Peter Wuille. ( I hope)
2232016-06-06T15:56:32 <hello_> MarcoFalke: Thank you
2242016-06-06T15:57:52 *** G1lius has quit IRC
2252016-06-06T15:58:17 <jl2012> sipa_ , instagibbs: we need to remind all alternative implementations to update their consensus rules
2262016-06-06T15:58:34 <instagibbs> roasbeef, ^^^
2272016-06-06T16:00:10 <jl2012> should I make an announcement on the ML?
2282016-06-06T16:01:24 <instagibbs> better safe than sorry
2292016-06-06T16:01:31 <btcdrak> yup
2302016-06-06T16:03:38 *** gevs has joined #bitcoin-core-dev
2312016-06-06T16:11:36 *** TomMc has quit IRC
2322016-06-06T16:13:05 *** G1lius has joined #bitcoin-core-dev
2332016-06-06T16:30:56 *** ozanyurt has quit IRC
2342016-06-06T16:31:02 *** ozanyurt_ has joined #bitcoin-core-dev
2352016-06-06T16:32:03 *** Chris_Stewart_5 has quit IRC
2362016-06-06T16:33:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2372016-06-06T16:45:56 *** TomMc has joined #bitcoin-core-dev
2382016-06-06T16:50:53 <sipa_> Lightsword: can you review https://github.com/bitcoin/bitcoin/pull/7935 ?
2392016-06-06T16:52:00 <sipa_> for breaking changes (not csv, but for segwit it would) it requires that explicit support be indicated in the GBT call request
2402016-06-06T16:53:00 <sipa_> (which makes sense, as they'd construct bogus blocks without, but i wonder if that's not a problem for downstream software)
2412016-06-06T16:53:28 <sipa_> perhaps a command-line flag saying "yes, my mining client supports feature X, don't require it to tell you every time" is more convenient
2422016-06-06T16:58:16 <luke-jr> and then have downstream software fail to implement it?..
2432016-06-06T16:58:27 <luke-jr> easier to just tell you every time
2442016-06-06T16:58:37 <luke-jr> especially considering this is GBT so there's no bandwidth savings from omitting it
2452016-06-06T16:58:59 *** Giszmo has quit IRC
2462016-06-06T16:59:08 <gmaxwell> commandline flag seems error prone, you don't upgrade one piece of downstream software and 20% of your infrastructure is producing invalid blocks.
2472016-06-06T17:00:40 *** ozanyurt_ has quit IRC
2482016-06-06T17:01:11 *** ozanyurt has joined #bitcoin-core-dev
2492016-06-06T17:02:21 <sipa_> luke-jr: that seems reasonable, but i haven't seen anyone comment on what changes this would require in their stack
2502016-06-06T17:03:03 <luke-jr> adding a key to the JSON object is trivial in every stack I know of
2512016-06-06T17:04:40 *** MarcoFalke has quit IRC
2522016-06-06T17:08:29 <Lightsword> sipa_, since stratum server requries a patch anyways can easially include the explicit support in the patch
2532016-06-06T17:08:53 <sipa_> ok, thanks
2542016-06-06T17:09:46 <Lightsword> sipa_, are there any potential issues with making a request indicating SW support to a non-SW capable node?
2552016-06-06T17:09:47 <Lightsword> itâs common to upgrade nodes separately from the stratum server
2562016-06-06T17:12:24 <sipa_> i do not believe that's a problem... you can always indicate support for more things than the server
2572016-06-06T17:13:02 <luke-jr> it shouldn't be a problem, GBT has always required the Object, and while bitcoind tolerates it being omitted, it also tolerates it being provided as spec'd
2582016-06-06T17:17:07 <sipa_> i think the PR always does what you'd expect; if you upgrade bitcoind before the client, it will not set the relevant bit by default during the started phase, and fail after activation (as you're unable to construct a valid block anymore)
2592016-06-06T17:17:20 <sipa_> if you upgrade the client before the server, no effect
2602016-06-06T17:48:42 <GitHub189> [bitcoin] pstratem opened pull request #8152: Remove CWalletDB* parameter from CWallet::AddToWallet (master...2016-06-06-cwallet-addtowallet-remove-cwalletdb) https://github.com/bitcoin/bitcoin/pull/8152
2612016-06-06T17:53:42 *** Chris_Stewart_5 has quit IRC
2622016-06-06T17:56:49 *** G1lius has quit IRC
2632016-06-06T18:00:21 *** sipa_ is now known as sipa
2642016-06-06T18:00:53 *** sipa has quit IRC
2652016-06-06T18:00:53 *** sipa has joined #bitcoin-core-dev
2662016-06-06T18:09:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2672016-06-06T18:10:04 *** tErik_mc has quit IRC
2682016-06-06T18:11:56 *** jtimon has quit IRC
2692016-06-06T18:12:28 <GitHub142> [bitcoin] MarcoFalke opened pull request #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB (master...Mf1606-univalAny) https://github.com/bitcoin/bitcoin/pull/8153
2702016-06-06T18:12:53 *** MarcoFalke has joined #bitcoin-core-dev
2712016-06-06T18:15:22 *** kadoban has joined #bitcoin-core-dev
2722016-06-06T18:15:44 <MarcoFalke> jonasschnelli: I think to make it BTC/kB, you'd need to modify univalue.
2732016-06-06T18:15:50 <MarcoFalke> (see pull)
2742016-06-06T18:17:32 <jonasschnelli> MarcoFalke: hmm.. i think you have added the VANY only because of the RPCTypeCheckObj check? Right?
2752016-06-06T18:17:42 <MarcoFalke> jup
2762016-06-06T18:17:55 <MarcoFalke> it is ugly
2772016-06-06T18:18:30 <jonasschnelli> Can you not add a third parameter to RPCTypeCheckObj's array?
2782016-06-06T18:18:36 <jonasschnelli> mandatory, or something...
2792016-06-06T18:23:25 <luke-jr> everyone is using satoshis per byte these days, which is much more logical in this case
2802016-06-06T18:23:33 <luke-jr> we haven't counted fees per kB in a long time
2812016-06-06T18:24:32 <sipa> i think consistency is more important
2822016-06-06T18:25:03 <luke-jr> I suppose
2832016-06-06T18:25:09 <jonasschnelli> sipa: agree with sipa
2842016-06-06T18:25:13 <luke-jr> it should probably be documented that it's not *actually* BTC/kB though
2852016-06-06T18:25:27 <sipa> how do you mean?
2862016-06-06T18:25:59 <luke-jr> in the RPC help or whatever
2872016-06-06T18:26:15 <jonasschnelli> If you use "estimatefee 10", you should be able to take the output as a fundrawtransaction feerate input
2882016-06-06T18:26:23 <jonasschnelli> so, BTC/kb
2892016-06-06T18:27:42 <luke-jr> mBTC/B
2902016-06-06T18:29:21 <MarcoFalke> luke-jr: Would work but you'd have to replace it in every doc/rpc help
2912016-06-06T18:29:39 <MarcoFalke> and I don't think it's less confusing
2922016-06-06T18:30:23 <jonasschnelli> If we should change the API, we would use satoshis everywhere.
2932016-06-06T18:30:36 <luke-jr> we switched from BTC/kB to mBTC/B in 0.10
2942016-06-06T18:30:43 <luke-jr> all the RPCs already use mBTC/B afaik
2952016-06-06T18:31:43 <jonasschnelli> luke-jr: estimatefee -> "(numeric) estimated fee-per-kilobyte"
2962016-06-06T18:31:59 * luke-jr is pretty sure that's a documentation error
2972016-06-06T18:32:06 <jonasschnelli> -minrelaytxfee -> Fee-per-kilobyte
2982016-06-06T18:33:18 <luke-jr> yeah, policy/fees.cpp uses CFeeRate, so estimatefee is almost certainly mBTC/B in practice
2992016-06-06T18:33:52 <jonasschnelli> maxtxfee: /** Absolute maximum transaction fee (in satoshis)
3002016-06-06T18:34:30 <luke-jr> anyway, this seems to be a deeper documentation issue than expected, so perhaps out of scope for MarcoFalke's PR
3012016-06-06T18:44:46 *** ozanyurt has quit IRC
3022016-06-06T18:45:05 *** ozanyurt has joined #bitcoin-core-dev
3032016-06-06T18:54:30 *** murch has joined #bitcoin-core-dev
3042016-06-06T18:59:43 *** ozanyurt has quit IRC
3052016-06-06T19:00:20 *** ozanyurt has joined #bitcoin-core-dev
3062016-06-06T19:02:43 *** BashCo has quit IRC
3072016-06-06T19:03:44 *** jtimon has joined #bitcoin-core-dev
3082016-06-06T19:04:32 <cfields_> luke-jr: could you please specify the case where you see "-dirty" and shouldn't? I
3092016-06-06T19:04:41 <cfields_> I'm missing some detail to reproduce
3102016-06-06T19:06:03 *** jarret has quit IRC
3112016-06-06T19:08:00 *** afk11 has quit IRC
3122016-06-06T19:09:21 <sipa> luke-jr: BTC/kB or mBTC/B is the same thing; i assume you're talking about whether it's counted per full byte or not... but fuel prices are also advertized per gallon, but counted at much smaller increments
3132016-06-06T19:10:07 <luke-jr> cfields_: git clone /path/to/your/repo -b branchname bitcoin && cd bitcoin && ./autogen.sh && mkdir build && sudo chown root:root -R . && sudo chown youruser build && cd build && ./configure && make && make DESTDIR=$PWD/ii install && ii/usr/local/bin/bitcoin-qt -testnet
3142016-06-06T19:10:12 <luke-jr> cfields_: it seems the chown is important
3152016-06-06T19:10:17 *** afk11 has joined #bitcoin-core-dev
3162016-06-06T19:10:17 *** afk11 has quit IRC
3172016-06-06T19:10:17 *** afk11 has joined #bitcoin-core-dev
3182016-06-06T19:10:35 <luke-jr> sipa: fair enough, but historically we have counted per full kB, so it's confusing
3192016-06-06T19:10:39 <cfields_> luke-jr: interesting. thanks.
3202016-06-06T19:11:25 <cfields_> luke-jr: just as an aside, you know about git new-workdir/git worktree, right?
3212016-06-06T19:11:32 <sipa> luke-jr: agree, but i guess we can add a "counted per byte" somewhere
3222016-06-06T19:11:35 <luke-jr> cfields_: no, I don't..
3232016-06-06T19:11:40 <sipa> worktree is awesome
3242016-06-06T19:12:00 <cfields_> luke-jr: ah, you'll want to google that then. sounds like you may be making your life harder if this test represents your workflow at all
3252016-06-06T19:12:22 <luke-jr> how is it different than git-clone?
3262016-06-06T19:12:41 <sipa> it doesn't create a new repository
3272016-06-06T19:12:50 <sipa> so not duplicate storage of the entire history
3282016-06-06T19:12:53 <cfields_> luke-jr: clone once, then have as many local checkouts in separate dirs as you want
3292016-06-06T19:13:10 <cfields_> ^^ what he said
3302016-06-06T19:13:12 <sipa> this creates multiple workdirs with the same repo
3312016-06-06T19:13:28 <luke-jr> git-clone uses hardlinks..
3322016-06-06T19:13:51 <sipa> ah, didn't know that
3332016-06-06T19:14:04 <sipa> well, it also has the advantage of not needing to push/pull between them
3342016-06-06T19:14:24 <cfields_> luke-jr: iirc the hardlinks are optional if you have fs restrictions
3352016-06-06T19:14:27 <luke-jr> ah
3362016-06-06T19:14:31 <luke-jr> that might be handy
3372016-06-06T19:15:03 <cfields_> sorry for the tangent, just thought it may be useful. I'll try to reproduce the case above.
3382016-06-06T19:15:17 <luke-jr> on another note, I wouldn't suggest using it with the test case I just gave, and might even want --no-hardlinks.. who knows what the chown will do :P
3392016-06-06T19:17:41 <cfields_> heh
3402016-06-06T19:21:16 *** Ylbam has quit IRC
3412016-06-06T19:22:33 *** BashCo has joined #bitcoin-core-dev
3422016-06-06T19:28:03 *** spudowiar has quit IRC
3432016-06-06T19:29:52 *** spudowiar has joined #bitcoin-core-dev
3442016-06-06T19:36:03 *** Chris_Stewart_5 has quit IRC
3452016-06-06T19:58:07 *** Ylbam has joined #bitcoin-core-dev
3462016-06-06T20:30:39 *** jiggalator has joined #bitcoin-core-dev
3472016-06-06T20:43:18 *** MarcoFalke has left #bitcoin-core-dev
3482016-06-06T21:01:30 *** raedah has quit IRC
3492016-06-06T21:02:59 *** raedah has joined #bitcoin-core-dev
3502016-06-06T21:08:01 *** Guyver2 has quit IRC
3512016-06-06T21:08:14 *** jannes has quit IRC
3522016-06-06T21:40:01 *** jiggalator has quit IRC
3532016-06-06T21:40:21 *** jiggalator has joined #bitcoin-core-dev
3542016-06-06T21:42:58 *** mkarrer has quit IRC
3552016-06-06T21:47:10 *** jiggalator has quit IRC
3562016-06-06T21:47:48 *** jiggalator has joined #bitcoin-core-dev
3572016-06-06T21:51:11 *** TomMc has quit IRC
3582016-06-06T21:52:25 *** jiggalator has quit IRC
3592016-06-06T21:56:13 *** supasonic has joined #bitcoin-core-dev
3602016-06-06T21:56:47 *** murch has quit IRC
3612016-06-06T22:13:46 *** jiggalator has joined #bitcoin-core-dev
3622016-06-06T22:17:15 <GitHub51> [bitcoin] kazcw opened pull request #8154: drop vAddrToSend after sending big addr message (master...drop-vAddrToSend) https://github.com/bitcoin/bitcoin/pull/8154
3632016-06-06T22:18:55 *** cryptapus is now known as cryptapus_afk
3642016-06-06T22:25:04 *** hello_ has quit IRC
3652016-06-06T22:30:00 *** frankenmint has joined #bitcoin-core-dev
3662016-06-06T22:43:15 *** frankenmint has quit IRC
3672016-06-06T22:43:16 *** cryptapus has joined #bitcoin-core-dev
3682016-06-06T22:43:16 *** cryptapus has joined #bitcoin-core-dev
3692016-06-06T22:48:52 *** cryptapus has quit IRC
3702016-06-06T22:52:36 *** frankenmint has joined #bitcoin-core-dev
3712016-06-06T22:56:43 *** TomMc has joined #bitcoin-core-dev
3722016-06-06T23:10:21 *** raedah has quit IRC
3732016-06-06T23:11:02 *** jiggalator is now known as nets1n
3742016-06-06T23:11:52 *** AaronvanW has quit IRC
3752016-06-06T23:12:07 *** Evel-Knievel has quit IRC
3762016-06-06T23:12:18 *** raedah has joined #bitcoin-core-dev
3772016-06-06T23:14:13 *** luke-jr has quit IRC
3782016-06-06T23:27:39 *** CubicEarth has joined #bitcoin-core-dev
3792016-06-06T23:48:39 *** CubicEarth has quit IRC
3802016-06-06T23:52:33 *** TomMc has quit IRC