1 2016-06-06 01:15:56	0|GitHub145|[13bitcoin] 15jmcorgan closed pull request #8148: Backport leveldb build integration to 0.12 (060.12...060.12) 02https://github.com/bitcoin/bitcoin/pull/8148
  2 2016-06-06 04:42:50	0|phantomcircuit|wumpus, fyi the two prs for wallet stuff dont merge cleanly against each other because of a trivial conflict
  3 2016-06-06 04:43:13	0|phantomcircuit|if one gets merged i will rebase the other and/or the merge can fix it
  4 2016-06-06 06:37:01	0|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
  5 2016-06-06 06:41:43	0|wumpus|oh nm it works, just slow
  6 2016-06-06 06:41:59	0|wumpus|and not for south african, somehow
  7 2016-06-06 08:34:54	0|GitHub130|13bitcoin/06master 14e6b141a 15Wladimir J. van der Laan: qt: translation strings update
  8 2016-06-06 08:34:54	0|GitHub130|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/e6b141acf9dcc0a12f49d53c0bb8a892bae72217
  9 2016-06-06 12:59:40	0|GitHub71|13bitcoin/06master 149dfaa1c 15Patrick Strateman: Improve CWallet API with new AccountMove function.
 10 2016-06-06 12:59:40	0|GitHub71|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e6b141acf9dc...243ac0c75b1b
 11 2016-06-06 12:59:41	0|GitHub71|13bitcoin/06master 14243ac0c 15Wladimir J. van der Laan: Merge #8137: Improve CWallet API with new AccountMove function....
 12 2016-06-06 12:59:50	0|GitHub112|[13bitcoin] 15laanwj closed pull request #8137: Improve CWallet API with new AccountMove function. (06master...062016-06-02-cwallet-accountmove) 02https://github.com/bitcoin/bitcoin/pull/8137
 13 2016-06-06 13:06:14	0|GitHub174|[13bitcoin] 15sipa opened pull request #8149: Segregated witness rebased (06master...06segwit-master2) 02https://github.com/bitcoin/bitcoin/pull/8149
 14 2016-06-06 13:13:54	0|sipa_|#8149 is 25% consensus/p2p/node changes, 10% wallet/signing changes, and 65% tests
 15 2016-06-06 13:14:04	0|sipa_|(the tests mostly due to sdaftuar)
 16 2016-06-06 13:15:27	0|sipa_|well, mostly is exaggerated, but more than half of it is from his p2p test
 17 2016-06-06 13:22:47	0|instagibbs|yes, those tests are very comprehensive, thanks sdaftuar :)
 18 2016-06-06 13:36:44	0|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)
 19 2016-06-06 13:39:56	0|sipa_|kanzure: done
 20 2016-06-06 13:45:59	0|GitHub6|13bitcoin/06master 14f0fdda0 15Kaz Wesley: IsInitialBlockDownload: usually avoid locking...
 21 2016-06-06 13:45:59	0|GitHub6|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/243ac0c75b1b...6b781df74fc2
 22 2016-06-06 13:46:00	0|GitHub6|13bitcoin/06master 146b781df 15Wladimir J. van der Laan: Merge #8007: Minor locking improvements...
 23 2016-06-06 13:46:08	0|GitHub99|[13bitcoin] 15laanwj closed pull request #8007: Minor locking improvements (06master...06locknits) 02https://github.com/bitcoin/bitcoin/pull/8007
 24 2016-06-06 13:46:32	0|cfields_|luke-jr: ping. I'm not seeing your "-dirty" behavior
 25 2016-06-06 13:46:48	0|MarcoFalke|sipa_: How do you plan to handle "segnet is not intended to be merged into Core"
 26 2016-06-06 13:47:13	0|MarcoFalke|is it going to be merged to result in the same tree hash?
 27 2016-06-06 13:47:40	0|sipa_|MarcoFalke: in 7910 i will add a commit to remove it; in 8149 is will be removed from history
 28 2016-06-06 13:48:41	0|sipa_|i'll keep updating both PRs now, as i don't expect many changes anymore
 29 2016-06-06 13:49:02	0|kanzure|i wonder if git can revert a (given) patch post-rebase
 30 2016-06-06 13:49:03	0|sipa_|but there are still a few (GBT, dns seeds, segnet, ...)
 31 2016-06-06 13:49:29	0|sipa_|kanzure: pretty sure it can, if it doesn't conflict
 32 2016-06-06 13:50:14	0|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)
 33 2016-06-06 13:50:49	0|sipa_|i'll just keep both in sync
 34 2016-06-06 13:50:57	0|MarcoFalke|Also, I think GitHub orders by commit date and not author date.
 35 2016-06-06 13:51:13	0|MarcoFalke|If that is something to care about
 36 2016-06-06 13:51:27	0|sipa_|MarcoFalke: that's why i provide my own list of commits...
 37 2016-06-06 13:51:38	0|sipa_|i want them to be dependency-ordered, not time
 38 2016-06-06 13:52:47	0|sdaftuar|sipa_: what's your preference for which PR we should post additional review comments?
 39 2016-06-06 13:53:41	0|sipa_|sdaftuar: 7910
 40 2016-06-06 13:53:42	0|MarcoFalke|Better keep it in 7910, so it is not all over the place?
 41 2016-06-06 13:53:58	0|sdaftuar|sounds good
 42 2016-06-06 14:03:28	0|instagibbs|might want to note that directly in both PRs
 43 2016-06-06 14:07:59	0|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.
 44 2016-06-06 14:08:38	0|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
 45 2016-06-06 14:09:04	0|wumpus|yes, the wording sounds good to me
 46 2016-06-06 14:09:27	0|wumpus|and indeed an option for confirm target would be nice too
 47 2016-06-06 14:09:55	0|wumpus|but that's something else, no need to do it there
 48 2016-06-06 14:11:28	0|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
 49 2016-06-06 14:11:55	0|MarcoFalke|Making it confirm target would change the behavior and users seem to be very sensitive to such wallet behavior changes
 50 2016-06-06 14:11:59	0|MarcoFalke|as we noticed in 0.12
 51 2016-06-06 14:12:03	0|helo|sorry to bikeshed... i know a confrimation target can't be guaranteed, but can it have confidence intervals to temper expectations?
 52 2016-06-06 14:12:24	0|wumpus|don't we already have a confirm target?
 53 2016-06-06 14:12:30	0|wumpus|this would just override the global steting
 54 2016-06-06 14:12:36	0|MarcoFalke|not for fundrawtx?
 55 2016-06-06 14:12:46	0|wumpus|ok, then only use it when the option is specified
 56 2016-06-06 14:13:03	0|wumpus|I  assumed it'd just use the global default confirmtarget unles specified otherwise
 57 2016-06-06 14:13:21	0|MarcoFalke|And if the users didn't set anything, it will also happen to "fall back" to txconfirmtarget
 58 2016-06-06 14:13:29	0|MarcoFalke|jup
 59 2016-06-06 14:13:31	0|wumpus|that's what I mean
 60 2016-06-06 14:14:17	0|wumpus|helo: if you find a way to compute those, sure
 61 2016-06-06 14:15:45	0|helo|i'll give it a shot, we'll see
 62 2016-06-06 14:17:30	0|sipa_|helo: it aims for 95% confidence, iirc
 63 2016-06-06 14:17:47	0|phantomcircuit|wumpus, rebased #8142
 64 2016-06-06 14:17:58	0|MarcoFalke|based on the observations from the past
 65 2016-06-06 14:18:00	0|wumpus|phantomcircuit: thanks
 66 2016-06-06 14:18:14	0|MarcoFalke|But I don't think you can figure out confidence intervals for the future
 67 2016-06-06 14:18:27	0|sipa_|MarcoFalke: of course
 68 2016-06-06 14:18:30	0|helo|yeah, you can't... just bayesian i'd assum
 69 2016-06-06 14:19:55	0|MarcoFalke|Yet another 32-bit 64-bit issue...
 70 2016-06-06 14:20:12	0|MarcoFalke|Can we forbid floating point multiplication for CAmount?
 71 2016-06-06 14:20:52	0|sipa_|MarcoFalke: where?
 72 2016-06-06 14:20:56	0|MarcoFalke|In the tests
 73 2016-06-06 14:21:15	0|MarcoFalke|behavior is not the same on 32bit arch and 64
 74 2016-06-06 14:22:03	0|wumpus|floating point for CAmounts? heresy!
 75 2016-06-06 14:22:10	0|MarcoFalke|.6 * 100000 sat will give 59999 sat on 32bit under some circumstances
 76 2016-06-06 14:23:01	0|wumpus|(and if you do you at least use correct rounding instead of truncation, but please don't use floating point for monetary amounts)
 77 2016-06-06 14:23:16	0|MarcoFalke|Haven't yet figured out why it is working right now, but I was doing some refactor and triggered it.
 78 2016-06-06 14:29:01	0|GitHub154|13bitcoin/06master 14152ab23 15Patrick Strateman: Improve CWallet API  with new GetAccountPubkey function....
 79 2016-06-06 14:29:01	0|GitHub154|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6b781df74fc2...52c3f348bec3
 80 2016-06-06 14:29:02	0|GitHub154|13bitcoin/06master 1452c3f34 15Wladimir J. van der Laan: Merge #8142: Improve CWallet API  with new GetAccountPubkey function....
 81 2016-06-06 14:29:12	0|GitHub33|[13bitcoin] 15laanwj closed pull request #8142: Improve CWallet API  with new GetAccountPubkey function. (06master...062016-06-02-cwallet-getaccountpubkey) 02https://github.com/bitcoin/bitcoin/pull/8142
 82 2016-06-06 14:40:49	0|sipa_|i'd like to see some P2P tests for the eviction logic being touched in #8084 etc
 83 2016-06-06 14:41:03	0|sipa_|but i don't know how to do that easily, as you'd need to spoof ip addresses
 84 2016-06-06 14:49:39	0|kanzure|maybe te network refactor stuff could make that easier?
 85 2016-06-06 14:49:41	0|kanzure|*the network
 86 2016-06-06 14:51:25	0|sipa_|i expect it to, indeed
 87 2016-06-06 14:56:49	0|luke-jr|cfields_: pong
 88 2016-06-06 15:31:09	0|GitHub72|[13bitcoin] 15MarcoFalke opened pull request #8151: [init] Make feefilter option debug option (06master...06Mf1606-feefilterDebug) 02https://github.com/bitcoin/bitcoin/pull/8151
 89 2016-06-06 15:31:17	0|MarcoFalke|wumpus, I think the issue is "JSONRPC error: Expected type number for feeRate, got string"
 90 2016-06-06 15:32:30	0|MarcoFalke|ups
 91 2016-06-06 15:32:36	0|MarcoFalke|forget what I said
 92 2016-06-06 15:33:57	0|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"
 93 2016-06-06 15:34:30	0|hello_|What is "invs" ... and what is the context here?
 94 2016-06-06 15:42:50	0|sipa_|helo: if you need to ask what invs are, then it's an indication that the messages is indeed too technical
 95 2016-06-06 15:42:57	0|sipa_|and that is the issue
 96 2016-06-06 15:43:20	0|gmaxwell|it's not even a setting an ordinary user should ever touch.
 97 2016-06-06 15:43:30	0|gmaxwell|-makemynodeworkworse
 98 2016-06-06 15:43:57	0|instagibbs|jl2012, have you adapted the BIP/PR for relaxing witness program size yet?
 99 2016-06-06 15:44:11	0|sipa_|instagibbs: yes, it's already included
100 2016-06-06 15:44:16	0|sipa_|(to length 40)
101 2016-06-06 15:46:05	0|instagibbs|ah thanks
102 2016-06-06 15:47:02	0|hello_|Well Im trying to  contribute to bitcoin... So I would be happy if you could just give a line of explanation. :) Cheers..
103 2016-06-06 15:47:43	0|hello_|sipa_: I already understand about 50% of the software so ....
104 2016-06-06 15:48:52	0|sipa_|hello_: i'll gladly explain things, but i don't think this is the place to explain the basic p2p protocol :)
105 2016-06-06 15:49:24	0|MarcoFalke|hello_: There is a bitcoin wiki with the basic description
106 2016-06-06 15:50:48	0|sipa_|hello_: https://bitcoin.org/en/developer-guide#transaction-broadcasting for explanation of the transaction relay protocol
107 2016-06-06 15:51:08	0|sipa_|hello_: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki for feefilter
108 2016-06-06 15:54:03	0|hello_|Thank you a lot Peter Wuille. ( I hope)
109 2016-06-06 15:56:33	0|hello_|MarcoFalke: Thank you
110 2016-06-06 15:58:18	0|jl2012|sipa_ , instagibbs: we need to remind all alternative implementations to update their consensus rules
111 2016-06-06 15:58:35	0|instagibbs|roasbeef, ^^^
112 2016-06-06 16:00:10	0|jl2012|should I make an announcement on the ML?
113 2016-06-06 16:01:24	0|instagibbs|better safe than sorry
114 2016-06-06 16:01:31	0|btcdrak|yup
115 2016-06-06 16:50:53	0|sipa_|Lightsword: can you review https://github.com/bitcoin/bitcoin/pull/7935 ?
116 2016-06-06 16:52:00	0|sipa_|for breaking changes (not csv, but for segwit it would) it requires that explicit support be indicated in the GBT call request
117 2016-06-06 16:53:01	0|sipa_|(which makes sense, as they'd construct bogus blocks without, but i wonder if that's not a problem for downstream software)
118 2016-06-06 16:53:29	0|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
119 2016-06-06 16:58:16	0|luke-jr|and then have downstream software fail to implement it?..
120 2016-06-06 16:58:27	0|luke-jr|easier to just tell you every time
121 2016-06-06 16:58:37	0|luke-jr|especially considering this is GBT so there's no bandwidth savings from omitting it
122 2016-06-06 16:59:08	0|gmaxwell|commandline flag seems error prone, you don't upgrade one piece of downstream software and 20% of your infrastructure is producing invalid blocks.
123 2016-06-06 17:02:21	0|sipa_|luke-jr: that seems reasonable, but i haven't seen anyone comment on what changes this would require in their stack
124 2016-06-06 17:03:03	0|luke-jr|adding a key to the JSON object is trivial in every stack I know of
125 2016-06-06 17:08:29	0|Lightsword|sipa_, since stratum server requries a patch anyways can easially include the explicit support in the patch
126 2016-06-06 17:08:53	0|sipa_|ok, thanks
127 2016-06-06 17:09:47	0|Lightsword|sipa_, are there any potential issues with making a request indicating SW support to a non-SW capable node?
128 2016-06-06 17:09:48	0|Lightsword|it’s common to upgrade nodes separately from the stratum server
129 2016-06-06 17:12:24	0|sipa_|i do not believe that's a problem... you can always indicate support for more things than the server
130 2016-06-06 17:13:03	0|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
131 2016-06-06 17:17:08	0|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)
132 2016-06-06 17:17:20	0|sipa_|if you upgrade the client before the server, no effect
133 2016-06-06 17:48:42	0|GitHub189|[13bitcoin] 15pstratem opened pull request #8152: Remove CWalletDB* parameter from CWallet::AddToWallet (06master...062016-06-06-cwallet-addtowallet-remove-cwalletdb) 02https://github.com/bitcoin/bitcoin/pull/8152
134 2016-06-06 18:12:28	0|GitHub142|[13bitcoin] 15MarcoFalke opened pull request #8153:  [rpc] fundrawtransaction feeRate: Use BTC/kB  (06master...06Mf1606-univalAny) 02https://github.com/bitcoin/bitcoin/pull/8153
135 2016-06-06 18:15:45	0|MarcoFalke|jonasschnelli: I think to make it BTC/kB, you'd need to modify univalue.
136 2016-06-06 18:15:50	0|MarcoFalke|(see pull)
137 2016-06-06 18:17:33	0|jonasschnelli|MarcoFalke: hmm.. i think you have added the VANY only because of the RPCTypeCheckObj check? Right?
138 2016-06-06 18:17:42	0|MarcoFalke|jup
139 2016-06-06 18:17:55	0|MarcoFalke|it is ugly
140 2016-06-06 18:18:30	0|jonasschnelli|Can you not add a third parameter to RPCTypeCheckObj's array?
141 2016-06-06 18:18:36	0|jonasschnelli|mandatory, or something...
142 2016-06-06 18:23:26	0|luke-jr|everyone is using satoshis per byte these days, which is much more logical in this case
143 2016-06-06 18:23:33	0|luke-jr|we haven't counted fees per kB in a long time
144 2016-06-06 18:24:33	0|sipa|i think consistency is more important
145 2016-06-06 18:25:04	0|luke-jr|I suppose
146 2016-06-06 18:25:10	0|jonasschnelli|sipa: agree with sipa
147 2016-06-06 18:25:13	0|luke-jr|it should probably be documented that it's not *actually* BTC/kB though
148 2016-06-06 18:25:27	0|sipa|how do you mean?
149 2016-06-06 18:25:59	0|luke-jr|in the RPC help or whatever
150 2016-06-06 18:26:15	0|jonasschnelli|If you use "estimatefee 10", you should be able to take the output as a fundrawtransaction feerate input
151 2016-06-06 18:26:24	0|jonasschnelli|so, BTC/kb
152 2016-06-06 18:27:43	0|luke-jr|mBTC/B
153 2016-06-06 18:29:21	0|MarcoFalke|luke-jr: Would work but you'd have to replace it in every doc/rpc help
154 2016-06-06 18:29:39	0|MarcoFalke|and I don't think it's less confusing
155 2016-06-06 18:30:24	0|jonasschnelli|If we should change the API, we would use satoshis everywhere.
156 2016-06-06 18:30:36	0|luke-jr|we switched from BTC/kB to mBTC/B in 0.10
157 2016-06-06 18:30:43	0|luke-jr|all the RPCs already use mBTC/B afaik
158 2016-06-06 18:31:44	0|jonasschnelli|luke-jr: estimatefee -> "(numeric) estimated fee-per-kilobyte"
159 2016-06-06 18:32:06	0|jonasschnelli|-minrelaytxfee -> Fee-per-kilobyte
160 2016-06-06 18:33:19	0|luke-jr|yeah, policy/fees.cpp uses CFeeRate, so estimatefee is almost certainly mBTC/B in practice
161 2016-06-06 18:33:53	0|jonasschnelli|maxtxfee: /** Absolute maximum transaction fee (in satoshis)
162 2016-06-06 18:34:31	0|luke-jr|anyway, this seems to be a deeper documentation issue than expected, so perhaps out of scope for MarcoFalke's PR
163 2016-06-06 19:04:33	0|cfields_|luke-jr: could you please specify the case where you see "-dirty" and shouldn't? I
164 2016-06-06 19:04:41	0|cfields_|I'm missing some detail to reproduce
165 2016-06-06 19:09:21	0|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
166 2016-06-06 19:10:07	0|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
167 2016-06-06 19:10:12	0|luke-jr|cfields_: it seems the chown is important
168 2016-06-06 19:10:36	0|luke-jr|sipa: fair enough, but historically we have counted per full kB, so it's confusing
169 2016-06-06 19:10:39	0|cfields_|luke-jr: interesting. thanks.
170 2016-06-06 19:11:25	0|cfields_|luke-jr: just as an aside, you know about git new-workdir/git worktree, right?
171 2016-06-06 19:11:33	0|sipa|luke-jr: agree, but i guess we can add a "counted per byte" somewhere
172 2016-06-06 19:11:35	0|luke-jr|cfields_: no, I don't..
173 2016-06-06 19:11:41	0|sipa|worktree is awesome
174 2016-06-06 19:12:01	0|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
175 2016-06-06 19:12:23	0|luke-jr|how is it different than git-clone?
176 2016-06-06 19:12:41	0|sipa|it doesn't create a new repository
177 2016-06-06 19:12:50	0|sipa|so not duplicate storage of the entire history
178 2016-06-06 19:12:54	0|cfields_|luke-jr: clone once, then have as many local checkouts in separate dirs as you want
179 2016-06-06 19:13:10	0|cfields_|^^ what he said
180 2016-06-06 19:13:12	0|sipa|this creates multiple workdirs with the same repo
181 2016-06-06 19:13:28	0|luke-jr|git-clone uses hardlinks..
182 2016-06-06 19:13:51	0|sipa|ah, didn't know that
183 2016-06-06 19:14:04	0|sipa|well, it also has the advantage of not needing to push/pull between them
184 2016-06-06 19:14:24	0|cfields_|luke-jr: iirc the hardlinks are optional if you have fs restrictions
185 2016-06-06 19:14:28	0|luke-jr|ah
186 2016-06-06 19:14:31	0|luke-jr|that might be handy
187 2016-06-06 19:15:03	0|cfields_|sorry for the tangent, just thought it may be useful. I'll try to reproduce the case above.
188 2016-06-06 19:15:18	0|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
189 2016-06-06 19:17:41	0|cfields_|heh
190 2016-06-06 22:17:15	0|GitHub51|[13bitcoin] 15kazcw opened pull request #8154: drop vAddrToSend after sending big addr message (06master...06drop-vAddrToSend) 02https://github.com/bitcoin/bitcoin/pull/8154