1 2016-04-08 05:41:01	0|gmaxwell|"minping": 9223372036854.775,
  2 2016-04-08 05:44:03	0|gmaxwell|interestingly one is on an outbound tor peer, another is on an inbound local peer.
  3 2016-04-08 05:44:09	0|gmaxwell|oh.. right this host is running core in valgrind.
  4 2016-04-08 06:44:39	0|wumpus|gmaxwell: there used to be a problem where minping was not initialized
  5 2016-04-08 06:45:09	0|michagogo|I kicked off my gitian build script last night before going to bed. Linux and Windows completed without any problems, but the OS X build failed
  6 2016-04-08 06:45:31	0|michagogo|It went as far as building protobuf, but then failed when extracting boost
  7 2016-04-08 06:45:33	0|wumpus|I managed to build all three - what's the issue?
  8 2016-04-08 06:46:13	0|michagogo|Tons of error messages from tar, cannot mkdir/open: read-only file system o_O
  9 2016-04-08 06:46:25	0|wumpus|gmaxwell: or is that std::numeric_limits<int64_t>::max()?
 10 2016-04-08 06:47:06	0|wumpus|yes it is. Okay that means that there hasn't been a ping ever
 11 2016-04-08 06:56:36	0|wumpus|unfortunately JSON in their infinite wisdom didn't take into account special floating point values like inf, NaN, -inf, so we cannot use those to indicate 'no ping ever'
 12 2016-04-08 06:57:23	0|gmaxwell|should we leave the field out in that case? we do that elsewhere for not-applicable; (I somewhat dislike this as it'll end up with a rare corner case that applications will not handle)
 13 2016-04-08 06:57:24	0|wumpus|and using a string or 'null' where people expect a value may be a bit mean (though a good way to check input validation)
 14 2016-04-08 06:57:55	0|wumpus|in any case whatever the behavior it needs to be documented in 'help' of the RPC call
 15 2016-04-08 07:00:30	0|wumpus|but hey, it's better than uninitialized memory, which it used to be before #6636
 16 2016-04-08 07:02:33	0|paveljanik|what about using negative value instead?
 17 2016-04-08 07:04:39	0|gmaxwell|then it probably sorts in the wrong position.
 18 2016-04-08 07:05:27	0|paveljanik|if it is not excluded from the sort as evidently invalid value, yes.
 19 2016-04-08 07:05:35	0|wumpus|it's not a good special marker. I think we return a negative result to mark 'unavailable information' in the fee estimaton calls and this confuses everyone, consistently
 20 2016-04-08 07:05:45	0|wumpus|I think sipa's 'null' makes most sense
 21 2016-04-08 07:06:29	0|wumpus|deleting the field completely may result in people complaiing 'oh noo why is this field not here it is documented!'
 22 2016-04-08 07:11:40	0|wumpus|do we have a way to make a node stop syncing at a certain block?
 23 2016-04-08 07:12:40	0|wumpus|oh I guess syncing until tip and then -connect=0.0.0.0 will do the job
 24 2016-04-08 07:16:18	0|jonasschnelli|wumpus: I was also looking for this some time ago (for the UTXO set dump). I hardcoded something.
 25 2016-04-08 07:17:07	0|wumpus|yes my idea now is to use one 'reference node' which does not receive new blocks, and make the other nodes sync from there
 26 2016-04-08 07:17:31	0|wumpus|i'm also comparing utxo set dumps :)
 27 2016-04-08 07:18:41	0|jonasschnelli|morcos: ping. Tell me when you have a couple of minutes to discuss the "new wallet" concerns.
 28 2016-04-08 07:19:13	0|wumpus|so something like my 'label API' would be new wallet only?
 29 2016-04-08 07:20:20	0|jonasschnelli|wumpus: Yes. I think it would be better.
 30 2016-04-08 07:20:36	0|jonasschnelli|Because we don't need to take care about the account compatibility.
 31 2016-04-08 07:20:46	0|wumpus|on the other hand it may give people a stepping stone to the new wallet
 32 2016-04-08 07:20:48	0|wumpus|I agree
 33 2016-04-08 07:21:02	0|jonasschnelli|But I'm fine with your PR for the old wallet.
 34 2016-04-08 07:21:35	0|jonasschnelli|I just think we should merge the new wallet as soon as it make sense (not now) and go with the tiny steps (PRs).
 35 2016-04-08 07:21:51	0|jonasschnelli|Peer reviews is really something that improves the quality.
 36 2016-04-08 07:22:22	0|jonasschnelli|And developing it on a different branch will lead to _no_ peer review and a very big PR if we consider merging it back to the master repo.
 37 2016-04-08 07:23:15	0|jonasschnelli|Merge ready could be: 1) remove accounts, 2) switch from BDB to LogDB, 3) simplify update logic
 38 2016-04-08 07:23:58	0|wumpus|yes we should at least prevent the infinite delay problem that haunts wallet changes, and just merge it without the idea that the API is stable
 39 2016-04-08 07:24:40	0|jonasschnelli|Yes. Just a code base where we can work on more aggressively and don't need to take care about every backward comp. API stableness.
 40 2016-04-08 07:26:15	0|wumpus|with the understanding that it will likely just be disabled for the 0.13 release
 41 2016-04-08 07:26:31	0|wumpus|or super-experimental
 42 2016-04-08 07:26:47	0|wumpus|depending on where things are
 43 2016-04-08 07:28:52	0|jonasschnelli|wumpus: yes. Certainly disabled for 0.13. My main short term focus is a new wallet codebase in the main repository to allow peer reviews.
 44 2016-04-08 07:29:06	0|jonasschnelli|Deploying it to the broad user base is something different.
 45 2016-04-08 07:29:17	0|jonasschnelli|Could be in 0.14, 0.15, depending on the progress.
 46 2016-04-08 07:29:32	0|wumpus|right
 47 2016-04-08 07:29:35	0|jonasschnelli|If it turns out as a bad idea, we can always remove it without loosing anything.
 48 2016-04-08 07:29:46	0|jonasschnelli|(before deployed)
 49 2016-04-08 07:29:53	0|wumpus|agree
 50 2016-04-08 07:32:53	0|jonasschnelli|wumpus: re: --enable-debug-lockorder, hmm... is there no use case to log the maybe-deadlocks but no assertion that kills the app?
 51 2016-04-08 07:34:22	0|wumpus|jonasschnelli: hey what a good idea
 52 2016-04-08 07:34:59	0|wumpus|yes that may be best, unless it kills the application in a logging flood of deadlock notifications
 53 2016-04-08 07:35:04	0|michagogo|10:11:40 <wumpus> do we have a way to make a node stop syncing at a certain block?
 54 2016-04-08 07:35:08	0|wumpus|but that's not my experience
 55 2016-04-08 07:35:12	0|michagogo|Does blacklisting do that?
 56 2016-04-08 07:35:31	0|wumpus|michagogo: but you can only blacklist a block *after* you have it, or not?
 57 2016-04-08 07:35:40	0|michagogo|wumpus: that's what I'm not sure about
 58 2016-04-08 07:36:08	0|michagogo|If that doesn't work, it should be made the case that it does :P
 59 2016-04-08 07:36:10	0|wumpus|it's worth a try, I considered it but then rejected it on that basis, maybe just knowning about the header is enough
 60 2016-04-08 07:38:11	0|wumpus|jonasschnelli: I vaguely remember we used to have those deadlock notifications non-fatal, then they would turn up here and there and people would report them but just carry on, it was less obnoxious than crashing, though still if it's false alarms ... :-)
 61 2016-04-08 07:40:21	0|jonasschnelli|I think we should --enable-debug-lockorder to enable the whole detections,.. and maybe just remove the fatal assert? But sipa said he know how to solve this. So i'll wait a bit.
 62 2016-04-08 07:41:10	0|wumpus|I think we should comment out the whole function until someone sorts out the problem
 63 2016-04-08 07:42:22	0|wumpus|then when brining it back we can make the decision, should it crash or just report
 64 2016-04-08 07:42:36	0|wumpus|but that's after we've fixed the non-sensical reports
 65 2016-04-08 07:43:48	0|jonasschnelli|Agree
 66 2016-04-08 07:44:32	0|wumpus|even having it as special autoconf option is not useful as long as it misfires
 67 2016-04-08 07:47:15	0|jonasschnelli|CHANELINFO: we have now a bitcoin-core-dev mailing list @ linux foundation. Please subscribe! https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev
 68 2016-04-08 07:49:06	0|jonasschnelli|Implementation details and things there where to much "Core-only" for bitcoin-dev list can now be discussed on bitcoin-core-dev
 69 2016-04-08 07:53:55	0|jonasschnelli|why the heck does "sendtoaddress" has a "comment" and a "comment-to" argument? Isn't this very confusing?
 70 2016-04-08 07:54:22	0|Luke-Jr|it's all confusing
 71 2016-04-08 07:54:24	0|wumpus|yes
 72 2016-04-08 07:54:26	0|wumpus|axe them
 73 2016-04-08 07:54:35	0|Luke-Jr|should really just be one comment/label per address. simple and clean.
 74 2016-04-08 07:54:38	0|sipa|it stores a comment on the address and a comment on the transaction, afaik :)
 75 2016-04-08 07:54:59	0|jonasschnelli|hmm... I think we should only have comments for transactions.
 76 2016-04-08 07:55:23	0|jonasschnelli|Doesn't labels for addresses as well as a "address book" implies address-resuse?
 77 2016-04-08 07:55:28	0|Luke-Jr|jonasschnelli: addresses are transactions; the difference is an address may not have a blockchain-transaction yet (ie, it might just be a request)
 78 2016-04-08 07:55:38	0|wumpus|no, not really, remember multiple addresses can have the same label jonasschnelli
 79 2016-04-08 07:55:45	0|wumpus|label is just a way to group addresses
 80 2016-04-08 07:56:03	0|jonasschnelli|wumpus: Ah. Right. That makes more sense.
 81 2016-04-08 07:56:09	0|wumpus|'all addresses I've sent to that belong to jonasschnelli'  etc
 82 2016-04-08 07:56:25	0|wumpus|'all addresses Ive used to receive from XYZ'
 83 2016-04-08 07:56:32	0|jonasschnelli|So a send-command then requires a comment (wtx) and a label (for the to address)
 84 2016-04-08 07:56:44	0|jonasschnelli|What about a label for the change-address? Not necessary i guess
 85 2016-04-08 07:56:53	0|wumpus|in any case, please make the command accept a structure
 86 2016-04-08 07:57:00	0|wumpus|so you can have optinoal arguments as well as extensibility
 87 2016-04-08 07:57:01	0|Luke-Jr|jonasschnelli: I don't see value in association with a wtx rather than an address.
 88 2016-04-08 07:57:07	0|wumpus|not the current positional hellscape
 89 2016-04-08 07:57:40	0|jonasschnelli|wumpus: Yes. What do you think in making the whole parameters for the new wallet an assoc. array? (A JSON object).
 90 2016-04-08 07:57:46	0|wumpus|we don't have to lock this down now if the API is extensible
 91 2016-04-08 07:57:50	0|wumpus|yes please
 92 2016-04-08 07:57:51	0|jonasschnelli|So each parameter has always a key
 93 2016-04-08 07:57:55	0|wumpus|right
 94 2016-04-08 07:58:15	0|jonasschnelli|Okay... and maybe also auto-detecting JSON object in bitcoin-cli to get rid of the static conversion table.
 95 2016-04-08 07:58:53	0|wumpus|yes I think a RPC call to get the command line to JSON conversion table would make sense
 96 2016-04-08 07:59:32	0|wumpus|although OTOH it's not a server concern, it's more like 'give me machine parsable docuentation'
 97 2016-04-08 08:00:32	0|jonasschnelli|Okay.
 98 2016-04-08 08:00:32	0|wumpus|(I've forgotten the exact name for this, but I think there's even an issue open about it, about automatic discoverability of the interfaces etc)
 99 2016-04-08 08:01:16	0|sipa|i remember something like that
100 2016-04-08 08:01:21	0|sipa|even some existing standard
101 2016-04-08 08:01:25	0|wumpus|right
102 2016-04-08 08:02:01	0|wumpus|'introspection' is the word
103 2016-04-08 08:02:09	0|jonasschnelli|But isn't the JSON conversion table something 100% on the client side?
104 2016-04-08 08:02:17	0|wumpus|https://github.com/bitcoin/bitcoin/issues/4157
105 2016-04-08 08:02:19	0|wumpus|bingo
106 2016-04-08 08:02:44	0|wumpus|jonasschnelli: well in a way it is, but other applciations (such as a nice ncurses based interactive console) may want the same information
107 2016-04-08 08:02:49	0|jonasschnelli|ah. Something like a WSDL
108 2016-04-08 08:03:18	0|wumpus|basically to help the client know what fields are expected, what types, etc, without having to hardcode this
109 2016-04-08 08:04:06	0|wumpus|"The only drawback that I see is that bitcoin-cli (and other RPC command-line clients) would effectively have to do two roundtrips to the server. Once to get instructions on how to convert the command-line parameters to JSON, and once to do the actual command."  apparently I forgot about a thing called caching :p
110 2016-04-08 08:05:11	0|jonasschnelli|wumpus: we could response a static JSON file that contains the "introspect". So people could store this on the client side.
111 2016-04-08 08:05:16	0|wumpus|exactly
112 2016-04-08 08:05:23	0|jonasschnelli|Like a SOAP WSDL
113 2016-04-08 08:05:43	0|jonasschnelli|Also, I'm not sure if a rpc-command prefix instead of a URL endpoint is more appropriate. At least the first is way more simple to implement.
114 2016-04-08 08:05:46	0|wumpus|mostly-static, it can change based on server configuration (different wallets, no wallet, etc)
115 2016-04-08 08:06:03	0|jonasschnelli|Agree
116 2016-04-08 08:06:06	0|GitHub117|[13bitcoin] 15fanquake opened pull request #7838: [Doc] Update gitian build guide to debian 8.4.0 (06master...06gitian-debian-84) 02https://github.com/bitcoin/bitcoin/pull/7838
117 2016-04-08 08:06:21	0|sipa|whenever you trigger a rpc type conversion error
118 2016-04-08 08:06:22	0|jonasschnelli|We could use /wallet for the new wallet commands... or wallet_command at the same root (/) endpoint
119 2016-04-08 08:06:31	0|jonasschnelli|sipa: +1
120 2016-04-08 08:06:39	0|sipa|you get the new table
121 2016-04-08 08:07:19	0|wumpus|or add an optional header to the RPC request: Fail-if-conversion-table-hash-is-not: XXXXX
122 2016-04-08 08:07:38	0|wumpus|then on failure retrieve the new list and do the conversion and request again
123 2016-04-08 08:08:33	0|wumpus|jonasschnelli: yes, different endpoints is also possible, we've discussed this in the path for multi-wallet support
124 2016-04-08 08:08:39	0|wumpus|in the PAST
125 2016-04-08 08:09:13	0|wumpus|you'd have to rewrite the RPC server a bit though so you instance it multiple times
126 2016-04-08 08:09:26	0|jonasschnelli|Yes. Command prefixes would be much simpler.
127 2016-04-08 08:09:39	0|jonasschnelli|Also the Multiwallet would be trivial with RPC argument structures.
128 2016-04-08 08:09:52	0|jonasschnelli|Just pass a {"wallet" : "wallet1", ... }
129 2016-04-08 08:10:03	0|wumpus|you mean command prefixes such as 'wallet.getinfo' 'mempool.getinfo' etc
130 2016-04-08 08:10:09	0|jonasschnelli|If no wallet is defined, use the "default" wallet
131 2016-04-08 08:10:14	0|wumpus|that won't help multiple wallets of the same type, of course
132 2016-04-08 08:10:27	0|wumpus|I wouldn't like wallet_wumpus.getinfo etc
133 2016-04-08 08:10:28	0|wumpus|right
134 2016-04-08 08:10:41	0|sipa|use separate url for each wallet
135 2016-04-08 08:11:04	0|jonasschnelli|url endpoints is non-trivial to implement.
136 2016-04-08 08:11:06	0|wumpus|does JSONRPC even allow dots in method names?
137 2016-04-08 08:11:11	0|wumpus|it's pretty trivial to implement jonasschnelli
138 2016-04-08 08:11:15	0|jonasschnelli|hmm.. good question. :)
139 2016-04-08 08:11:28	0|sipa|jonasschnelli: it means that different wallets with different api can be loaded simultaneously
140 2016-04-08 08:11:29	0|wumpus|we've done quite some work in making that possible already
141 2016-04-08 08:11:46	0|jonasschnelli|okay... need to look at this.
142 2016-04-08 08:11:50	0|wumpus|just means we need some refactors which we really want anyway
143 2016-04-08 08:11:55	0|jonasschnelli|sipa: can you explain: "different wallets with different api can be loaded simultaneously"?
144 2016-04-08 08:12:11	0|wumpus|yes, if they have different endpoints, they can co-exist without even noticiing each other
145 2016-04-08 08:12:20	0|wumpus|(assuming they won't touch the same files etc)
146 2016-04-08 08:12:45	0|sipa|jonasschnelli: say we have a schnelliwallet, and then later someone implement a super simple sipwallet with a different api, using the same rpc table for both won't work
147 2016-04-08 08:12:48	0|jonasschnelli|something like /wallet/mywallet/getinfo and wallet/createnewwallet
148 2016-04-08 08:13:13	0|sipa|jonasschnelli: if they run on different urls, you get that for free
149 2016-04-08 08:13:16	0|wumpus|in any case, let's not do this all at once, the new wallet explicitly doesn't have a stable interface in the beginning
150 2016-04-08 08:13:31	0|jonasschnelli|okay.
151 2016-04-08 08:13:50	0|jonasschnelli|A /wallet endpoint makes sense for now I guess.
152 2016-04-08 08:14:04	0|jonasschnelli|Also for further process de-coupeling.
153 2016-04-08 08:14:12	0|jonasschnelli|(which is out of scope for now)
154 2016-04-08 08:14:31	0|wumpus|yes, URL separateion also brings that
155 2016-04-08 08:14:32	0|wumpus|good point
156 2016-04-08 08:14:57	0|gmaxwell|01:11 < wumpus> it's pretty trivial to implement jonasschnelli
157 2016-04-08 08:15:15	0|jonasschnelli|gmaxwell: lol...
158 2016-04-08 08:15:18	0|wumpus|people will already instance multiple RPC proxies so whether that points to two URLs on the same server or different ports is a detail
159 2016-04-08 08:15:21	0|wumpus|gmaxwell: hahahahah oops
160 2016-04-08 08:16:45	0|jonasschnelli|Hm... now for the "bumpfee" RBF feature,.. do I really need to add a 6. argument to "sendtoaddress"? I can't see a better option to opt-into-RBF.
161 2016-04-08 08:17:54	0|gmaxwell|start adding data to the address field with delimiters that can't be in addresses.
162 2016-04-08 08:18:57	0|jonasschnelli|gmaxwell: almost as good as "sendtoaddress-with-rfb" :-)
163 2016-04-08 08:19:07	0|gmaxwell|incidentally when comming up with new wallet-apis, it really should be possible to do things like "send all my funds, minus whatever fees are needed" or even "send at least x, but you can send a bit more to avoid creating change".
164 2016-04-08 08:19:11	0|wumpus|or just encode all arguments into the address with a special prefix
165 2016-04-08 08:19:34	0|gmaxwell|wumpus: we have that api already, it's called 'sendrawtransaction' :)
166 2016-04-08 08:20:24	0|wumpus|gmaxwell: this is for the old wallet API, for the new one the argument will be a structure so there's flexibility and expansibility, for the old one we're stuck with positional argument madness
167 2016-04-08 08:20:28	0|jonasschnelli|gmaxwell: "send all my funds, minus whatever fees are needed" is think  this is already possible npw
168 2016-04-08 08:20:50	0|jonasschnelli|gmaxwell: sendtoaddress(<adr>, getbalance(), subtractfeefromamount=true)
169 2016-04-08 08:20:57	0|wumpus|yes 'subtractfeefromamount'
170 2016-04-08 08:21:16	0|jonasschnelli|Which is an awesome feature IMO
171 2016-04-08 08:21:21	0|wumpus|it's just that you don't want to add even more boolean arguments, like one for 'you can send a bit more to avoid creating change'
172 2016-04-08 08:21:42	0|wumpus|which should be possible with a better API
173 2016-04-08 08:22:16	0|jonasschnelli|wumpus: hah. True. I saw many people trying to move their balance from one to another wallet by slowly picking the total amount (like a in-human-fee-estimator)
174 2016-04-08 08:23:41	0|wumpus|haha yes I think I've done that once too
175 2016-04-08 08:24:20	0|wumpus|bisecting the number
176 2016-04-08 08:25:01	0|gmaxwell|oh when did that get added! I missed that.
177 2016-04-08 08:25:21	0|gmaxwell|that bisect behavior also then results in some stupid tiny amount being left in the wallet often.
178 2016-04-08 08:26:11	0|gmaxwell|but yes, it was just an aside comment for new APIs.
179 2016-04-08 09:11:12	0|jonasschnelli|Hmm... doesn't this lead to wrong fee calculation: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1960
180 2016-04-08 09:11:23	0|jonasschnelli|(adding inputs after CreateTransaction)
181 2016-04-08 09:11:43	0|jonasschnelli|ping TheBlueMatt
182 2016-04-08 09:20:53	0|jonasschnelli|Never-mind! It's correct.
183 2016-04-08 12:13:18	0|GitHub69|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5851915a006a...232592a71f02
184 2016-04-08 12:13:19	0|GitHub69|13bitcoin/06master 14232592a 15Wladimir J. van der Laan: Merge #7570: Net: Add IPv6 Link-Local Address Support...
185 2016-04-08 12:13:19	0|GitHub69|13bitcoin/06master 14eda3d92 15mruddy: Net: Add IPv6 Link-Local Address Support
186 2016-04-08 12:13:22	0|GitHub33|[13bitcoin] 15laanwj closed pull request #7570: Net: Add IPv6 Link-Local Address Support (06master...06ipv6-link-local) 02https://github.com/bitcoin/bitcoin/pull/7570
187 2016-04-08 12:18:14	0|GitHub179|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/232592a71f02...0afac87e8173
188 2016-04-08 12:18:15	0|GitHub179|13bitcoin/06master 145cb1d8a 15Suhas Daftuar: Tests: move get_bip9_status to util.py
189 2016-04-08 12:18:15	0|GitHub179|13bitcoin/06master 14e4ba9f6 15Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
190 2016-04-08 12:18:16	0|GitHub179|13bitcoin/06master 14da5fdbb 15Suhas Daftuar: Test relay of version 2 transactions
191 2016-04-08 12:18:24	0|GitHub186|[13bitcoin] 15laanwj closed pull request #7835: Version 2 transactions remain non-standard until CSV activates (06master...06CSV-relay-after-softfork) 02https://github.com/bitcoin/bitcoin/pull/7835
192 2016-04-08 12:22:38	0|GitHub78|13bitcoin/060.12 1446898e7 15Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
193 2016-04-08 12:22:38	0|GitHub78|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/46898e7e942b4e04021aac3724eb4f2ec4cf567b
194 2016-04-08 12:26:07	0|GitHub35|13bitcoin/060.12 14465d309 15Wladimir J. van der Laan: doc: update release notes for #7835
195 2016-04-08 12:26:07	0|GitHub35|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/465d30915cd3c1634b32f942c1faae32967e9805
196 2016-04-08 12:26:39	0|wumpus|* [new tag]         v0.12.1rc2 -> v0.12.1rc2
197 2016-04-08 12:41:11	0|michagogo|wumpus: script running, should push sigs shortly
198 2016-04-08 12:41:18	0|wumpus|thanks!
199 2016-04-08 12:41:38	0|michagogo|If the previous PR is still around it'll just update that (and confuse the script), otherwise there'll be a new one
200 2016-04-08 12:41:43	0|MarcoFalke|Has anyone run the test suite on 0.12 yet?
201 2016-04-08 12:42:31	0|michagogo|(That last part isn't really a problem-- even though it runs in bash -e, it's the last line of the script IIRC so it shouldn't hurt anything)
202 2016-04-08 12:44:23	0|GitHub17|[13bitcoin] 15dragongem45 opened pull request #7839: Expose information on whether transaction relayed is enabled in getne… (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/7839
203 2016-04-08 12:48:58	0|MarcoFalke|Is there a difference between `int(unsigned(1))` and `static_cast<int>(unsigned(1))`?
204 2016-04-08 12:53:01	0|sipa|MarcoFalke: no, both will return the same int
205 2016-04-08 12:53:16	0|sipa|MarcoFalke: the first is weird C, the second is weird C++ :)
206 2016-04-08 12:55:24	0|MarcoFalke|but they are different from `(int) ((unsigned) (1))`?
207 2016-04-08 12:55:38	0|MarcoFalke|Assuming int and unsigned are any primitive type.
208 2016-04-08 12:56:59	0|sipa|TYPE(VAL) is only valid in C++
209 2016-04-08 12:57:09	0|sipa|in C you have to use (TYPE)VAL
210 2016-04-08 12:57:35	0|sipa|int(5) is technically invoking the C++ constructor for int, with argument 5
211 2016-04-08 12:57:43	0|sipa|(int)5 is a C cast from 5 to int
212 2016-04-08 12:57:54	0|sipa|static_cast<int>(5) is a C++ cast from 5 to int
213 2016-04-08 12:58:17	0|wumpus|TYPE(VAL) syntax also doesn't work with e.g. pointer types, and other types that aren't one word because they have specifiers (e.g. unsigned int)
214 2016-04-08 12:58:50	0|MarcoFalke|You can put (unsigned int) into braces and it should work, I think
215 2016-04-08 12:58:59	0|wumpus|yes but that's just a C cast then
216 2016-04-08 12:59:44	0|MarcoFalke|Ok, I was wondering what is preferred. E.g. static_cast<int>(nSize) or int(nSize)
217 2016-04-08 12:59:49	0|MarcoFalke|re: negative fee rates
218 2016-04-08 12:59:58	0|sipa|the first
219 2016-04-08 13:00:24	0|MarcoFalke|so it's clear that a cast is happening?
220 2016-04-08 13:00:50	0|sipa|the latter is C style, and its behaviour is a bit unpredictable
221 2016-04-08 13:01:03	0|wumpus|I don't really care, more important when casting between int types is to handle overflows and underflows properly ,none of the C/C++ casts does that in itself
222 2016-04-08 13:01:19	0|sipa|MarcoFalke: see point 1 here: http://en.cppreference.com/w/cpp/language/explicit_cast
223 2016-04-08 13:02:42	0|wumpus|but yes in C++ using a C++ cast is probably best
224 2016-04-08 13:02:57	0|wumpus|isn't int(X) c++ syntax too, though?
225 2016-04-08 13:03:10	0|wumpus|in C, int doesn't have a constructor
226 2016-04-08 13:03:23	0|sipa|int(X) is C++, yes
227 2016-04-08 13:03:23	0|wumpus|you could only do (int)X
228 2016-04-08 13:03:28	0|sipa|but it's not a cast :)
229 2016-04-08 13:03:48	0|sipa|... semantics, though
230 2016-04-08 13:03:51	0|wumpus|what is the difference in practice?
231 2016-04-08 13:04:02	0|wumpus|(for int, for other objects it probably invokes different methods)
232 2016-04-08 13:04:18	0|sipa|ok, i learned today:
233 2016-04-08 13:04:19	0|sipa|The functional cast expression consists of a simple type specifier or a typedef specifier (in other words, a single-word type name: unsigned int(expression) or int*(expression) are not valid), followed by a single expression in parentheses. This cast expression is exactly equivalent to the corresponding C-style cast expression.
234 2016-04-08 13:04:42	0|wumpus|ah, that makes sense
235 2016-04-08 13:04:44	0|sipa|so it's just extra C++ syntax equivalent to a C cast, with the same magic behaviour
236 2016-04-08 13:26:32	0|wumpus|I don't understand this line (target-bin/upgrade-system.sh in gitian): DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade > /dev/null > /var/cache/gitian/upgrade.log 2>&1
237 2016-04-08 13:26:55	0|wumpus|what is sent to /dev/null and what to the log file?
238 2016-04-08 13:30:03	0|wumpus|(my guess is everything goes to /dev/null and the second > is ignored, but I just don't know the syntax)
239 2016-04-08 13:30:29	0|helo|everything ends up in /var/cache/gitian/upgrade.log (out and err)
240 2016-04-08 13:30:43	0|wumpus|then what does the /dev/null do?
241 2016-04-08 13:31:07	0|sipa|wumpus: i believe i know the syntax, and that >/dev/null is redundant
242 2016-04-08 13:31:08	0|helo|nothing
243 2016-04-08 13:31:16	0|wumpus|okay
244 2016-04-08 13:32:14	0|sipa|just tested it
245 2016-04-08 13:32:19	0|sipa|(echo "stdout"; echo "stderr" >&2) >/dev/null >file 2>&1
246 2016-04-08 13:32:25	0|sipa|writes both stdout and stderr to file
247 2016-04-08 13:33:04	0|wumpus|awesome, thanks
248 2016-04-08 13:38:12	0|MarcoFalke|wumpus, do you really want to assert(int(nSize)>0)? nSize must represent a size of some GB (~ 1e9 GB, I think)...
249 2016-04-08 13:39:10	0|wumpus|should be >=0 I think?
250 2016-04-08 13:39:28	0|GitHub164|[13bitcoin] 15sipa opened pull request #7840: Split and optimize inv queues and improve mempool privacy (06master...06splitinvtxblock) 02https://github.com/bitcoin/bitcoin/pull/7840
251 2016-04-08 13:40:01	0|wumpus|but yes, such an assertion makes sense, to make sure the number is within the right range
252 2016-04-08 13:41:12	0|wumpus|I don't think it'll ever trigger but better be safe than sorry
253 2016-04-08 13:42:06	0|MarcoFalke|You don't want to have some code to be triggered by p2p which will cause the assert to fail ...
254 2016-04-08 13:42:24	0|MarcoFalke|And remotly shut down any node
255 2016-04-08 13:42:36	0|wumpus|that may be preferrable to the alternative, whatever happens with the big negative fee
256 2016-04-08 13:42:57	0|MarcoFalke|if(nSize<0)nSize=max_nr
257 2016-04-08 13:43:01	0|MarcoFalke|what about this?
258 2016-04-08 13:43:39	0|wumpus|I don't like that, if somethat that wrong happens it's better to just stop, ignoring issues is worse than simply handling them
259 2016-04-08 13:43:50	0|MarcoFalke|ok
260 2016-04-08 13:44:11	0|wumpus|it's a bug in our code if a size of ~1e9 GB reaches the fee rate function
261 2016-04-08 13:46:47	0|morcos|wumpus: are you sure that should be the case (that it's a bug?).  ok i guess 1e9 GB, maybe makes sense..  but you could make the argument that someone would use CFeeRate to report the average fee rate of the whole mempool or something.
262 2016-04-08 13:47:07	0|wumpus|well it overflows the integer range
263 2016-04-08 13:47:22	0|morcos|In other words, i think maybe its ok to have some reasonable limit, but maybe we should clearly flag that rather than just making assumptions on how CFeeRate is used..
264 2016-04-08 13:47:22	0|wumpus|how would you handle that?
265 2016-04-08 13:47:24	0|helo|should data type validity be ensured during deserialization?
266 2016-04-08 13:48:39	0|morcos|I guess i just don't have a good mental model of where/when CFeeRate is used.  So I agree good for it to be a bug when it overflows, but lets make sure that limit is high enough and comment the limitations well in CFeeRate.  1e9GB seems fine to me
267 2016-04-08 13:48:53	0|wumpus|I'm tired of this discussion already, I personally feel bad about silent c++ signed/unsigned casts and the potential overflow scenarios, but feel free to just ignore the issue for CFeerate.
268 2016-04-08 13:49:22	0|MarcoFalke|Will add the assert and the doc
269 2016-04-08 13:49:28	0|MarcoFalke|Hopefully everyone is happy then
270 2016-04-08 13:49:32	0|wumpus|as fee rates are not used to address into arrays this will probably never result in exploitable scenarios  or memory crashes
271 2016-04-08 13:49:59	0|morcos|Yeah all I'm trying to suggest is that we make our assumptions explicit, sorry I probably didn't state that clearly
272 2016-04-08 13:50:04	0|morcos|so sounds good
273 2016-04-08 13:51:03	0|wumpus|the point is that a size_t can be larger than std::numeric_limits<int64_t>::max()  on most platforms
274 2016-04-08 13:51:20	0|sipa|use ptrdiff_t *ducks*
275 2016-04-08 13:51:23	0|wumpus|so before the cast it makes sense to check that the value is <= that
276 2016-04-08 13:51:50	0|wumpus|what you do in that case depends on the circumstances, but in this case as it shoudl be a bug if such a big value reaches it an assertion makes sense, I'd think
277 2016-04-08 13:52:09	0|wumpus|sipa: right, that would just move the issue to the interface :)
278 2016-04-08 13:53:16	0|wumpus|so if you say "it should be able to handle the entire mempool", I still think it would be an abomination if the mempool was larger than half the virtual address space on 64-bit platforms :)
279 2016-04-08 13:53:40	0|GitHub19|[13bitcoin] 15dragongem45 closed pull request #7839: Expose information on whether transaction relayed is enabled in getne… (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/7839
280 2016-04-08 14:01:24	0|wumpus|helo: probably, as the deserializer has knowledge of the types involved
281 2016-04-08 14:08:45	0|wumpus|if it doesn't check type validity, then who will? having deserialized objects in memory constructed with invalid bit patterns could be a security or stability issue
282 2016-04-08 14:09:35	0|wumpus|shit, just wiped the gitian output again by starting before I copied out the executables
283 2016-04-08 14:18:02	0|GitHub24|[13bitcoin] 15dragongem45 opened pull request #7841: Expose information on whether transaction relayed is enabled in getnetwork (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/7841
284 2016-04-08 14:38:11	0|morcos|sdaftuar: wumpus: i got a failure of bip68-sequence.py in 0.12.1rc2 .  but its intermittant.  looking into it.
285 2016-04-08 14:50:54	0|morcos|i suspect the problem is that if the version of your bitcoind that generated your cache is old then the CSV activation doesn't happen as expected in that test
286 2016-04-08 15:00:35	0|morcos|yes thats the problem, i was confused b/c there are two cache directories.  one in pull-tester and one in rpc-tests
287 2016-04-08 15:00:55	0|morcos|would it make sense for make clean to wipe out the cache directories?
288 2016-04-08 15:07:23	0|morcos|jonasschnelli: oops forgot to ping you.  i'm here.
289 2016-04-08 15:48:35	0|wumpus|morcos: so removing the cache made the problem go away?
290 2016-04-08 16:07:26	0|morcos|wumpus: yep.  it works fine with a fresh cache.
291 2016-04-08 16:07:40	0|morcos|it makes sense that the old cache wouldn't work
292 2016-04-08 16:07:41	0|wumpus|phew!
293 2016-04-08 16:41:12	0|btcdrak|why are gitian builds so slow in comparison to building on a non VM using same number of cores to compile with?
294 2016-04-08 16:43:07	0|MarcoFalke|depends take the longest time
295 2016-04-08 16:53:18	0|sdaftuar|morcos: oops, thanks for figuring it out.  seems innocuous enough to not worry about fixing in 0.12.1?
296 2016-04-08 16:58:46	0|GitHub122|[13bitcoin] 15paveljanik opened pull request #7842: RPC: do not print minping time in getpeerinfo when no ping received yet (06master...0620160408_getpeerinfo_no_ping_yet) 02https://github.com/bitcoin/bitcoin/pull/7842
297 2016-04-08 17:11:21	0|instagibbs|during a reorg, when(if ever) does a node re-broadcast transactions that have re-entered the mempool
298 2016-04-08 17:21:44	0|morcos|instagibbs: i assume it does not
299 2016-04-08 17:24:32	0|instagibbs|matches up with my testing just making sure
300 2016-04-08 17:25:02	0|instagibbs|python testing kind of breaks when that happens, since many times it checks to ensure that mempools are synced
301 2016-04-08 17:47:17	0|btcdrak|interesting. I just noticed Github has started verifying GPG signed commits if you give it your key https://i.imgur.com/MNIYMm0.png
302 2016-04-08 17:47:43	0|sipa|btcdrak: yup, i uploaded mine
303 2016-04-08 17:47:56	0|btcdrak|https://i.imgur.com/KWHyAxe.png
304 2016-04-08 17:47:59	0|btcdrak|yeah that's cool.
305 2016-04-08 17:49:39	0|sipa|drommels drommels en nog eens drommels
306 2016-04-08 17:50:40	0|btcdrak|"devils devils and further rattling"
307 2016-04-08 19:25:45	0|cfields_|gitian builders: 0.12.1rc2 signatures are pushed
308 2016-04-08 19:26:25	0|ThomasV|are there ongoing projects to implement a utxo merkle tree in bitcoind ?
309 2016-04-08 19:30:44	0|ThomasV|btcdrak: you used to work on addrindex, is it still active?
310 2016-04-08 19:31:10	0|btcdrak|yes
311 2016-04-08 19:31:31	0|ThomasV|how does it work?
312 2016-04-08 19:31:37	0|btcdrak|See my fork
313 2016-04-08 19:32:07	0|sipa|ThomasV: you one that is committed to by the blockchain?
314 2016-04-08 19:32:12	0|sipa|*mean
315 2016-04-08 19:32:58	0|ThomasV|sipa: obviouly not.. you already told me that is not planned
316 2016-04-08 19:33:14	0|sipa|then why do you need to be a merkle tree?
317 2016-04-08 19:33:27	0|sipa|:)
318 2016-04-08 19:34:11	0|sipa|i am planning to make the gettxoutsetinfo RPC call compute a merkle on the fly of the utxo set (indexed by txid, not by address)
319 2016-04-08 19:34:40	0|sipa|so there could be future calls that query and produce proofs about it
320 2016-04-08 19:35:22	0|ThomasV|sipa: what kind of proofs do you mean?
321 2016-04-08 19:35:47	0|sipa|ThomasV: assuming that you get that merkle root from a trusted place, i can prove to you that a particular utxo exists or doesn't exist
322 2016-04-08 19:36:12	0|ThomasV|sipa: long term I want to add versum to electrum servers
323 2016-04-08 19:36:17	0|sipa|versum?
324 2016-04-08 19:36:22	0|ThomasV|https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj7s5S35P_LAhUI2SwKHYP7Du4QFggdMAA&url=https%3A%2F%2Fpeople.csail.mit.edu%2Fnickolai%2Fpapers%2Fvandenhooff-versum.pdf&usg=AFQjCNHfZH5-aM9YEgKwhDKqOjZBuugEMA
325 2016-04-08 19:36:37	0|ThomasV|err https://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf
326 2016-04-08 19:36:57	0|ThomasV|unless utxo commitments happen, of course
327 2016-04-08 19:37:27	0|ThomasV|that's why I prefer a merkle tree
328 2016-04-08 19:37:34	0|sipa|ok, i'll read it later
329 2016-04-08 19:39:40	0|ThomasV|sipa: btw, why is it that you decided to index by txid ?
330 2016-04-08 19:40:20	0|sipa|ThomasV: because that's what matters for validation
331 2016-04-08 19:41:12	0|ThomasV|oh sure
332 2016-04-08 19:41:22	0|sipa|constructing a merkle tree at least requires to have the data ordered by the lookup key
333 2016-04-08 19:41:32	0|sipa|and we already have the utxo set ordered by txid
334 2016-04-08 19:42:50	0|sipa|ThomasV: where are you based, btw?
335 2016-04-08 19:42:58	0|ThomasV|in Berlin
336 2016-04-08 19:43:21	0|ThomasV|btcdrak: which branch should I look at?
337 2016-04-08 19:44:13	0|btcdrak|addrindex-0.12
338 2016-04-08 19:44:29	0|btcdrak|also tagged and binaries built in releases tab
339 2016-04-08 19:46:29	0|sipa|ThomasV: ah, i'm in stuttgart currently
340 2016-04-08 19:47:00	0|ThomasV|sipa: permanently? I thought you were in zurich
341 2016-04-08 19:47:09	0|sipa|ThomasV: no, for a few days
342 2016-04-08 19:47:14	0|ThomasV|k
343 2016-04-08 19:51:52	0|GitHub61|[13bitcoin] 15initaldk opened pull request #7843: Delete CONTRIBUTING.md (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/7843
344 2016-04-08 20:04:03	0|GitHub172|[13bitcoin] 15sipa closed pull request #7843: Delete CONTRIBUTING.md (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/7843
345 2016-04-08 20:29:38	0|ThomasV|stuttgart is much closer to zurich than to berlin :)
346 2016-04-08 20:39:05	0|ThomasV|time to watch spacex tv..
347 2016-04-08 20:58:28	0|matthew_english|hi paveljanik
348 2016-04-08 20:58:50	0|paveljanik|matthew_english, Hi!
349 2016-04-08 20:59:05	0|matthew_english|:)
350 2016-04-08 20:59:37	0|matthew_english|so- do you think we might be able to figure out how to commit this silly change?
351 2016-04-08 20:59:48	0|paveljanik|yup
352 2016-04-08 21:00:05	0|paveljanik|please do again step by step what I wrote to you and lets pause in vi :-)
353 2016-04-08 21:00:06	0|matthew_english|thank you for your help thus far also
354 2016-04-08 21:00:12	0|matthew_english|ok coo
355 2016-04-08 21:00:15	0|matthew_english|cool
356 2016-04-08 21:00:27	0|matthew_english|so I'll delete the repo and reclone it- one moment...
357 2016-04-08 21:00:37	0|paveljanik|yes
358 2016-04-08 21:00:40	0|paveljanik|I'll do it here too
359 2016-04-08 21:00:55	0|matthew_english|ok
360 2016-04-08 21:01:00	0|matthew_english|i downloaded my own fork
361 2016-04-08 21:01:32	0|matthew_english|alright
362 2016-04-08 21:01:35	0|matthew_english|now I'm in vi
363 2016-04-08 21:01:52	0|paveljanik|so you see two lines starting with pick, right?
364 2016-04-08 21:02:06	0|matthew_english|righto
365 2016-04-08 21:02:19	0|matthew_english|haha I'm a sublime user
366 2016-04-08 21:02:20	0|paveljanik|so go to the second line
367 2016-04-08 21:02:21	0|matthew_english|very lame
368 2016-04-08 21:02:22	0|matthew_english|but
369 2016-04-08 21:02:25	0|matthew_english|I want to start using emacs
370 2016-04-08 21:02:35	0|matthew_english|ok
371 2016-04-08 21:02:42	0|matthew_english|and must press 'i' isn't it?
372 2016-04-08 21:02:47	0|paveljanik|push x to delete one character, repeat until there is no p i c k :-)
373 2016-04-08 21:03:02	0|matthew_english|ok
374 2016-04-08 21:03:05	0|matthew_english|done
375 2016-04-08 21:03:08	0|paveljanik|then i and type squash or s, it is enough
376 2016-04-08 21:03:18	0|paveljanik|so your first line reads pick something
377 2016-04-08 21:03:21	0|paveljanik|second line s something
378 2016-04-08 21:03:31	0|paveljanik|then you are ready to exit
379 2016-04-08 21:03:35	0|matthew_english|ok cool
380 2016-04-08 21:03:36	0|paveljanik|Esc : wq
381 2016-04-08 21:03:37	0|matthew_english|the :q
382 2016-04-08 21:03:41	0|matthew_english|ah ok cool
383 2016-04-08 21:03:46	0|paveljanik|you know more than me :-)
384 2016-04-08 21:04:08	0|paveljanik|This command instructs git to squash the second commit, to hide it
385 2016-04-08 21:04:21	0|paveljanik|and now you'll see git commit message
386 2016-04-08 21:04:22	0|matthew_english|to make the two into one
387 2016-04-08 21:04:24	0|matthew_english|I guess
388 2016-04-08 21:04:31	0|matthew_english|hmm
389 2016-04-08 21:04:35	0|paveljanik|it contains both lines - from the first and also from the second squashed commit
390 2016-04-08 21:04:43	0|paveljanik|right?
391 2016-04-08 21:04:49	0|paveljanik|they are both the same in your case.
392 2016-04-08 21:04:59	0|matthew_english|can I do 'git status' to see it?
393 2016-04-08 21:05:18	0|paveljanik|you can use git log (in the other terminal, yes)
394 2016-04-08 21:05:27	0|paveljanik|but you are in the middle of rebase...
395 2016-04-08 21:05:53	0|matthew_english|I did git log
396 2016-04-08 21:05:56	0|paveljanik|git log shows you commit messages
397 2016-04-08 21:05:58	0|paveljanik|yes
398 2016-04-08 21:05:59	0|matthew_english|but I don't see a commit message
399 2016-04-08 21:06:18	0|matthew_english|it just says 'update polcy.cpp' twice
400 2016-04-08 21:06:47	0|paveljanik|we will move to PM
401 2016-04-08 21:37:29	0|GitHub111|[13bitcoin] 15sipa opened pull request #7846: Clean up lockorder data of destroyed mutexes (06master...06cleanlocks) 02https://github.com/bitcoin/bitcoin/pull/7846
402 2016-04-08 21:49:16	0|Chris_Stewart_5|Does the 'bool' returned by EvalScript inside of interpreter indicate that the transaction has been marked invalid, or that the script execution ended in the returned bool value?'
403 2016-04-08 21:50:01	0|sipa|EvalScript just evaluates, it doesn't check success conditions
404 2016-04-08 21:50:12	0|sipa|so if it returns false, it means an error occurred
405 2016-04-08 21:50:24	0|sipa|VerifyScript tests the success conditions for use in transactions
406 2016-04-08 21:50:33	0|Chris_Stewart_5|because shouldn't the top of the stack indicate if the script exectuion was true/false?
407 2016-04-08 21:50:46	0|sipa|yes, VerifyScript tests that
408 2016-04-08 21:51:46	0|Chris_Stewart_5|gotcha. Thanks for the clarification
409 2016-04-08 22:00:36	0|kanzure|for emails rejected on the bitcoin-core-dev mailing list, should they also be forwarded to bitcoin-dev-moderation@lists.ozlabs.org or should that feed remain for bitcoin-dev mailing list rejection only?
410 2016-04-08 22:58:12	0|GitHub158|[13bitcoin] 15gmaxwell closed pull request #7805: Eliminate TX trickle bypass, sort TX invs for privacy and priority. (06master...06sorted_invs) 02https://github.com/bitcoin/bitcoin/pull/7805