1 2016-04-08T00:09:28  *** Amnez777 has quit IRC
  2 2016-04-08T00:12:01  *** Amnez777 has joined #bitcoin-core-dev
  3 2016-04-08T00:26:11  *** fengling has joined #bitcoin-core-dev
  4 2016-04-08T00:30:36  *** fengling has quit IRC
  5 2016-04-08T00:31:19  *** johnwhitton has joined #bitcoin-core-dev
  6 2016-04-08T00:37:25  *** frankenmint has joined #bitcoin-core-dev
  7 2016-04-08T00:38:59  *** jtimon has quit IRC
  8 2016-04-08T00:43:08  *** frankenmint has quit IRC
  9 2016-04-08T00:45:20  *** fengling has joined #bitcoin-core-dev
 10 2016-04-08T00:48:35  *** OGF-US has left #bitcoin-core-dev
 11 2016-04-08T00:51:03  *** Ylbam has quit IRC
 12 2016-04-08T00:55:51  *** gevs has quit IRC
 13 2016-04-08T01:22:21  *** spikeheadon has quit IRC
 14 2016-04-08T01:30:06  *** dermoth has quit IRC
 15 2016-04-08T01:30:56  *** dermoth has joined #bitcoin-core-dev
 16 2016-04-08T01:41:57  *** belcher has quit IRC
 17 2016-04-08T02:00:25  *** dermoth has quit IRC
 18 2016-04-08T02:00:58  *** dermoth has joined #bitcoin-core-dev
 19 2016-04-08T02:15:13  *** Giszmo has quit IRC
 20 2016-04-08T02:15:58  *** Giszmo has joined #bitcoin-core-dev
 21 2016-04-08T02:19:01  *** Alopex has quit IRC
 22 2016-04-08T02:20:06  *** Alopex has joined #bitcoin-core-dev
 23 2016-04-08T02:34:10  *** davec has quit IRC
 24 2016-04-08T02:36:20  *** davec has joined #bitcoin-core-dev
 25 2016-04-08T02:44:50  *** xiangfu has joined #bitcoin-core-dev
 26 2016-04-08T02:47:34  *** afk11 has quit IRC
 27 2016-04-08T02:50:25  *** afk11 has joined #bitcoin-core-dev
 28 2016-04-08T02:53:29  *** arowser has joined #bitcoin-core-dev
 29 2016-04-08T02:54:30  *** laurentmt has joined #bitcoin-core-dev
 30 2016-04-08T02:54:30  *** laurentmt has quit IRC
 31 2016-04-08T03:01:55  *** zooko has quit IRC
 32 2016-04-08T03:05:06  *** PaulCape_ has joined #bitcoin-core-dev
 33 2016-04-08T03:07:34  *** PaulCapestany has quit IRC
 34 2016-04-08T03:31:33  *** xiangfu has quit IRC
 35 2016-04-08T03:35:22  *** Giszmo has quit IRC
 36 2016-04-08T04:03:01  *** Alopex has quit IRC
 37 2016-04-08T04:04:06  *** Alopex has joined #bitcoin-core-dev
 38 2016-04-08T04:35:02  *** Alopex has quit IRC
 39 2016-04-08T04:36:07  *** Alopex has joined #bitcoin-core-dev
 40 2016-04-08T05:04:42  *** Luke-Jr has quit IRC
 41 2016-04-08T05:14:16  *** fkhan_ has quit IRC
 42 2016-04-08T05:30:36  *** fengling has quit IRC
 43 2016-04-08T05:30:53  *** fkhan_ has joined #bitcoin-core-dev
 44 2016-04-08T05:40:01  *** Alopex has quit IRC
 45 2016-04-08T05:41:01  <gmaxwell>     "minping": 9223372036854.775,
 46 2016-04-08T05:41:06  *** Alopex has joined #bitcoin-core-dev
 47 2016-04-08T05:44:03  <gmaxwell> interestingly one is on an outbound tor peer, another is on an inbound local peer.
 48 2016-04-08T05:44:09  <gmaxwell> oh.. right this host is running core in valgrind.
 49 2016-04-08T05:47:17  *** frankenmint has joined #bitcoin-core-dev
 50 2016-04-08T05:49:53  *** Luke-Jr has joined #bitcoin-core-dev
 51 2016-04-08T05:49:58  *** frankenmint has quit IRC
 52 2016-04-08T05:51:02  *** frankenmint has joined #bitcoin-core-dev
 53 2016-04-08T05:56:01  *** Alopex has quit IRC
 54 2016-04-08T05:57:06  *** Alopex has joined #bitcoin-core-dev
 55 2016-04-08T06:00:08  *** dermoth has quit IRC
 56 2016-04-08T06:00:47  *** dermoth has joined #bitcoin-core-dev
 57 2016-04-08T06:04:08  *** Thireus has joined #bitcoin-core-dev
 58 2016-04-08T06:04:52  *** fengling has joined #bitcoin-core-dev
 59 2016-04-08T06:07:37  *** Ylbam has joined #bitcoin-core-dev
 60 2016-04-08T06:18:02  *** Alopex has quit IRC
 61 2016-04-08T06:19:07  *** Alopex has joined #bitcoin-core-dev
 62 2016-04-08T06:30:49  *** johnwhitton has quit IRC
 63 2016-04-08T06:35:17  *** johnwhitton has joined #bitcoin-core-dev
 64 2016-04-08T06:38:17  *** johnwhitton has quit IRC
 65 2016-04-08T06:38:41  *** johnwhitton has joined #bitcoin-core-dev
 66 2016-04-08T06:41:00  *** johnwhitton has joined #bitcoin-core-dev
 67 2016-04-08T06:43:08  *** johnwhitton has quit IRC
 68 2016-04-08T06:44:16  *** [Author] has quit IRC
 69 2016-04-08T06:44:39  <wumpus> gmaxwell: there used to be a problem where minping was not initialized
 70 2016-04-08T06:45:09  <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
 71 2016-04-08T06:45:31  <michagogo> It went as far as building protobuf, but then failed when extracting boost
 72 2016-04-08T06:45:34  <wumpus> I managed to build all three - what's the issue?
 73 2016-04-08T06:46:13  <michagogo> Tons of error messages from tar, cannot mkdir/open: read-only file system o_O
 74 2016-04-08T06:46:26  <wumpus> gmaxwell: or is that std::numeric_limits<int64_t>::max()?
 75 2016-04-08T06:47:06  <wumpus> yes it is. Okay that means that there hasn't been a ping ever
 76 2016-04-08T06:51:41  *** spikeheadon has joined #bitcoin-core-dev
 77 2016-04-08T06:51:56  *** abritoid has joined #bitcoin-core-dev
 78 2016-04-08T06:53:25  *** [Author] has joined #bitcoin-core-dev
 79 2016-04-08T06:56:36  <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'
 80 2016-04-08T06:57:23  <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)
 81 2016-04-08T06:57:24  <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)
 82 2016-04-08T06:57:55  <wumpus> in any case whatever the behavior it needs to be documented in 'help' of the RPC call
 83 2016-04-08T07:00:30  <wumpus> but hey, it's better than uninitialized memory, which it used to be before #6636
 84 2016-04-08T07:02:34  <paveljanik> what about using negative value instead?
 85 2016-04-08T07:04:39  <gmaxwell> then it probably sorts in the wrong position.
 86 2016-04-08T07:05:27  <paveljanik> if it is not excluded from the sort as evidently invalid value, yes.
 87 2016-04-08T07:05:35  <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
 88 2016-04-08T07:05:46  <wumpus> I think sipa's 'null' makes most sense
 89 2016-04-08T07:06:29  <wumpus> deleting the field completely may result in people complaiing 'oh noo why is this field not here it is documented!'
 90 2016-04-08T07:11:40  <wumpus> do we have a way to make a node stop syncing at a certain block?
 91 2016-04-08T07:12:40  <wumpus> oh I guess syncing until tip and then -connect= will do the job
 92 2016-04-08T07:16:08  *** johnwhitton has joined #bitcoin-core-dev
 93 2016-04-08T07:16:18  <jonasschnelli> wumpus: I was also looking for this some time ago (for the UTXO set dump). I hardcoded something.
 94 2016-04-08T07:17:07  <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
 95 2016-04-08T07:17:31  <wumpus> i'm also comparing utxo set dumps :)
 96 2016-04-08T07:18:41  <jonasschnelli> morcos: ping. Tell me when you have a couple of minutes to discuss the "new wallet" concerns.
 97 2016-04-08T07:19:13  <wumpus> so something like my 'label API' would be new wallet only?
 98 2016-04-08T07:20:20  <jonasschnelli> wumpus: Yes. I think it would be better.
 99 2016-04-08T07:20:33  *** johnwhitton has quit IRC
100 2016-04-08T07:20:37  <jonasschnelli> Because we don't need to take care about the account compatibility.
101 2016-04-08T07:20:46  <wumpus> on the other hand it may give people a stepping stone to the new wallet
102 2016-04-08T07:20:48  <wumpus> I agree
103 2016-04-08T07:21:02  <jonasschnelli> But I'm fine with your PR for the old wallet.
104 2016-04-08T07:21:24  *** johnwhitton has joined #bitcoin-core-dev
105 2016-04-08T07:21:35  <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).
106 2016-04-08T07:21:52  <jonasschnelli> Peer reviews is really something that improves the quality.
107 2016-04-08T07:22:22  <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.
108 2016-04-08T07:23:15  <jonasschnelli> Merge ready could be: 1) remove accounts, 2) switch from BDB to LogDB, 3) simplify update logic
109 2016-04-08T07:23:58  <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
110 2016-04-08T07:24:41  <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.
111 2016-04-08T07:26:15  <wumpus> with the understanding that it will likely just be disabled for the 0.13 release
112 2016-04-08T07:26:31  <wumpus> or super-experimental
113 2016-04-08T07:26:47  <wumpus> depending on where things are
114 2016-04-08T07:28:52  <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.
115 2016-04-08T07:29:06  <jonasschnelli> Deploying it to the broad user base is something different.
116 2016-04-08T07:29:17  <jonasschnelli> Could be in 0.14, 0.15, depending on the progress.
117 2016-04-08T07:29:32  <wumpus> right
118 2016-04-08T07:29:35  <jonasschnelli> If it turns out as a bad idea, we can always remove it without loosing anything.
119 2016-04-08T07:29:46  <jonasschnelli> (before deployed)
120 2016-04-08T07:29:54  <wumpus> agree
121 2016-04-08T07:32:53  <jonasschnelli> wumpus: re: --enable-debug-lockorder, hmm... is there no use case to log the maybe-deadlocks but no assertion that kills the app?
122 2016-04-08T07:34:22  <wumpus> jonasschnelli: hey what a good idea
123 2016-04-08T07:34:59  <wumpus> yes that may be best, unless it kills the application in a logging flood of deadlock notifications
124 2016-04-08T07:35:04  <michagogo> 10:11:40 <wumpus> do we have a way to make a node stop syncing at a certain block?
125 2016-04-08T07:35:08  <wumpus> but that's not my experience
126 2016-04-08T07:35:12  <michagogo> Does blacklisting do that?
127 2016-04-08T07:35:31  <wumpus> michagogo: but you can only blacklist a block *after* you have it, or not?
128 2016-04-08T07:35:40  <michagogo> wumpus: that's what I'm not sure about
129 2016-04-08T07:36:08  <michagogo> If that doesn't work, it should be made the case that it does :P
130 2016-04-08T07:36:11  <wumpus> it's worth a try, I considered it but then rejected it on that basis, maybe just knowning about the header is enough
131 2016-04-08T07:38:11  <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 ... :-)
132 2016-04-08T07:40:21  <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.
133 2016-04-08T07:41:11  <wumpus> I think we should comment out the whole function until someone sorts out the problem
134 2016-04-08T07:42:22  <wumpus> then when brining it back we can make the decision, should it crash or just report
135 2016-04-08T07:42:36  <wumpus> but that's after we've fixed the non-sensical reports
136 2016-04-08T07:43:48  <jonasschnelli> Agree
137 2016-04-08T07:44:33  <wumpus> even having it as special autoconf option is not useful as long as it misfires
138 2016-04-08T07:47:15  <jonasschnelli> CHANELINFO: we have now a bitcoin-core-dev mailing list @ linux foundation. Please subscribe! https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev
139 2016-04-08T07:49:06  <jonasschnelli> Implementation details and things there where to much "Core-only" for bitcoin-dev list can now be discussed on bitcoin-core-dev
140 2016-04-08T07:53:56  <jonasschnelli> why the heck does "sendtoaddress" has a "comment" and a "comment-to" argument? Isn't this very confusing?
141 2016-04-08T07:54:22  <Luke-Jr> it's all confusing
142 2016-04-08T07:54:24  <wumpus> yes
143 2016-04-08T07:54:26  <wumpus> axe them
144 2016-04-08T07:54:36  <Luke-Jr> should really just be one comment/label per address. simple and clean.
145 2016-04-08T07:54:38  <sipa> it stores a comment on the address and a comment on the transaction, afaik :)
146 2016-04-08T07:54:59  <jonasschnelli> hmm... I think we should only have comments for transactions.
147 2016-04-08T07:55:23  <jonasschnelli> Doesn't labels for addresses as well as a "address book" implies address-resuse?
148 2016-04-08T07:55:28  <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)
149 2016-04-08T07:55:38  <wumpus> no, not really, remember multiple addresses can have the same label jonasschnelli
150 2016-04-08T07:55:45  <wumpus> label is just a way to group addresses
151 2016-04-08T07:56:03  <jonasschnelli> wumpus: Ah. Right. That makes more sense.
152 2016-04-08T07:56:09  <wumpus> 'all addresses I've sent to that belong to jonasschnelli'  etc
153 2016-04-08T07:56:25  <wumpus> 'all addresses Ive used to receive from XYZ'
154 2016-04-08T07:56:32  <jonasschnelli> So a send-command then requires a comment (wtx) and a label (for the to address)
155 2016-04-08T07:56:44  <jonasschnelli> What about a label for the change-address? Not necessary i guess
156 2016-04-08T07:56:53  <wumpus> in any case, please make the command accept a structure
157 2016-04-08T07:57:00  <wumpus> so you can have optinoal arguments as well as extensibility
158 2016-04-08T07:57:01  <Luke-Jr> jonasschnelli: I don't see value in association with a wtx rather than an address.
159 2016-04-08T07:57:07  <wumpus> not the current positional hellscape
160 2016-04-08T07:57:41  <jonasschnelli> wumpus: Yes. What do you think in making the whole parameters for the new wallet an assoc. array? (A JSON object).
161 2016-04-08T07:57:46  <wumpus> we don't have to lock this down now if the API is extensible
162 2016-04-08T07:57:50  <wumpus> yes please
163 2016-04-08T07:57:51  <jonasschnelli> So each parameter has always a key
164 2016-04-08T07:57:55  <wumpus> right
165 2016-04-08T07:58:15  <jonasschnelli> Okay... and maybe also auto-detecting JSON object in bitcoin-cli to get rid of the static conversion table.
166 2016-04-08T07:58:54  <wumpus> yes I think a RPC call to get the command line to JSON conversion table would make sense
167 2016-04-08T07:59:32  <wumpus> although OTOH it's not a server concern, it's more like 'give me machine parsable docuentation'
168 2016-04-08T08:00:32  <jonasschnelli> Okay.
169 2016-04-08T08:00:32  <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)
170 2016-04-08T08:01:16  <sipa> i remember something like that
171 2016-04-08T08:01:21  <sipa> even some existing standard
172 2016-04-08T08:01:25  <wumpus> right
173 2016-04-08T08:02:01  <wumpus> 'introspection' is the word
174 2016-04-08T08:02:10  <jonasschnelli> But isn't the JSON conversion table something 100% on the client side?
175 2016-04-08T08:02:17  <wumpus> https://github.com/bitcoin/bitcoin/issues/4157
176 2016-04-08T08:02:19  <wumpus> bingo
177 2016-04-08T08:02:25  * jonasschnelli looking...
178 2016-04-08T08:02:44  <wumpus> jonasschnelli: well in a way it is, but other applciations (such as a nice ncurses based interactive console) may want the same information
179 2016-04-08T08:02:49  <jonasschnelli> ah. Something like a WSDL
180 2016-04-08T08:03:18  <wumpus> basically to help the client know what fields are expected, what types, etc, without having to hardcode this
181 2016-04-08T08:04:06  <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
182 2016-04-08T08:05:11  <jonasschnelli> wumpus: we could response a static JSON file that contains the "introspect". So people could store this on the client side.
183 2016-04-08T08:05:16  <wumpus> exactly
184 2016-04-08T08:05:23  <jonasschnelli> Like a SOAP WSDL
185 2016-04-08T08:05:43  <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.
186 2016-04-08T08:05:47  <wumpus> mostly-static, it can change based on server configuration (different wallets, no wallet, etc)
187 2016-04-08T08:06:03  <jonasschnelli> Agree
188 2016-04-08T08:06:07  <GitHub117> [bitcoin] fanquake opened pull request #7838: [Doc] Update gitian build guide to debian 8.4.0 (master...gitian-debian-84) https://github.com/bitcoin/bitcoin/pull/7838
189 2016-04-08T08:06:21  <sipa> whenever you trigger a rpc type conversion error
190 2016-04-08T08:06:23  <jonasschnelli> We could use /wallet for the new wallet commands... or wallet_command at the same root (/) endpoint
191 2016-04-08T08:06:32  <jonasschnelli> sipa: +1
192 2016-04-08T08:06:39  <sipa> you get the new table
193 2016-04-08T08:07:19  <wumpus> or add an optional header to the RPC request: Fail-if-conversion-table-hash-is-not: XXXXX
194 2016-04-08T08:07:38  <wumpus> then on failure retrieve the new list and do the conversion and request again
195 2016-04-08T08:08:34  <wumpus> jonasschnelli: yes, different endpoints is also possible, we've discussed this in the path for multi-wallet support
196 2016-04-08T08:08:39  <wumpus> in the PAST
197 2016-04-08T08:09:13  <wumpus> you'd have to rewrite the RPC server a bit though so you instance it multiple times
198 2016-04-08T08:09:26  <jonasschnelli> Yes. Command prefixes would be much simpler.
199 2016-04-08T08:09:31  *** p15x has joined #bitcoin-core-dev
200 2016-04-08T08:09:39  <jonasschnelli> Also the Multiwallet would be trivial with RPC argument structures.
201 2016-04-08T08:09:52  <jonasschnelli> Just pass a {"wallet" : "wallet1", ... }
202 2016-04-08T08:10:03  <wumpus> you mean command prefixes such as 'wallet.getinfo' 'mempool.getinfo' etc
203 2016-04-08T08:10:10  <jonasschnelli> If no wallet is defined, use the "default" wallet
204 2016-04-08T08:10:14  <wumpus> that won't help multiple wallets of the same type, of course
205 2016-04-08T08:10:27  <wumpus> I wouldn't like wallet_wumpus.getinfo etc
206 2016-04-08T08:10:28  <wumpus> right
207 2016-04-08T08:10:41  <sipa> use separate url for each wallet
208 2016-04-08T08:10:47  * jonasschnelli likes the <dot>. syntax.
209 2016-04-08T08:11:04  <jonasschnelli> url endpoints is non-trivial to implement.
210 2016-04-08T08:11:06  <wumpus> does JSONRPC even allow dots in method names?
211 2016-04-08T08:11:11  <wumpus> it's pretty trivial to implement jonasschnelli
212 2016-04-08T08:11:15  <jonasschnelli> hmm.. good question. :)
213 2016-04-08T08:11:28  <sipa> jonasschnelli: it means that different wallets with different api can be loaded simultaneously
214 2016-04-08T08:11:29  <wumpus> we've done quite some work in making that possible already
215 2016-04-08T08:11:46  <jonasschnelli> okay... need to look at this.
216 2016-04-08T08:11:50  <wumpus> just means we need some refactors which we really want anyway
217 2016-04-08T08:11:55  <jonasschnelli> sipa: can you explain: "different wallets with different api can be loaded simultaneously"?
218 2016-04-08T08:12:12  <wumpus> yes, if they have different endpoints, they can co-exist without even noticiing each other
219 2016-04-08T08:12:20  <wumpus> (assuming they won't touch the same files etc)
220 2016-04-08T08:12:45  <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
221 2016-04-08T08:12:48  <jonasschnelli> something like /wallet/mywallet/getinfo and wallet/createnewwallet
222 2016-04-08T08:13:13  <sipa> jonasschnelli: if they run on different urls, you get that for free
223 2016-04-08T08:13:17  <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
224 2016-04-08T08:13:31  <jonasschnelli> okay.
225 2016-04-08T08:13:50  <jonasschnelli> A /wallet endpoint makes sense for now I guess.
226 2016-04-08T08:14:05  <jonasschnelli> Also for further process de-coupeling.
227 2016-04-08T08:14:12  <jonasschnelli> (which is out of scope for now)
228 2016-04-08T08:14:31  <wumpus> yes, URL separateion also brings that
229 2016-04-08T08:14:32  <wumpus> good point
230 2016-04-08T08:14:57  * gmaxwell reads things out of context
231 2016-04-08T08:14:57  <gmaxwell> 01:11 < wumpus> it's pretty trivial to implement jonasschnelli
232 2016-04-08T08:15:02  *** jannes has joined #bitcoin-core-dev
233 2016-04-08T08:15:15  <jonasschnelli> gmaxwell: lol...
234 2016-04-08T08:15:18  <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
235 2016-04-08T08:15:21  <wumpus> gmaxwell: hahahahah oops
236 2016-04-08T08:16:46  <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.
237 2016-04-08T08:17:54  <gmaxwell> start adding data to the address field with delimiters that can't be in addresses.
238 2016-04-08T08:17:57  * gmaxwell ducks
239 2016-04-08T08:18:57  <jonasschnelli> gmaxwell: almost as good as "sendtoaddress-with-rfb" :-)
240 2016-04-08T08:19:07  <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".
241 2016-04-08T08:19:11  <wumpus> or just encode all arguments into the address with a special prefix
242 2016-04-08T08:19:34  <gmaxwell> wumpus: we have that api already, it's called 'sendrawtransaction' :)
243 2016-04-08T08:20:25  <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
244 2016-04-08T08:20:28  <jonasschnelli> gmaxwell: "send all my funds, minus whatever fees are needed" is think  this is already possible npw
245 2016-04-08T08:20:50  <jonasschnelli> gmaxwell: sendtoaddress(<adr>, getbalance(), subtractfeefromamount=true)
246 2016-04-08T08:20:57  <wumpus> yes 'subtractfeefromamount'
247 2016-04-08T08:21:16  <jonasschnelli> Which is an awesome feature IMO
248 2016-04-08T08:21:21  <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'
249 2016-04-08T08:21:42  <wumpus> which should be possible with a better API
250 2016-04-08T08:22:16  <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)
251 2016-04-08T08:23:41  <wumpus> haha yes I think I've done that once too
252 2016-04-08T08:24:20  <wumpus> bisecting the number
253 2016-04-08T08:25:01  <gmaxwell> oh when did that get added! I missed that.
254 2016-04-08T08:25:22  <gmaxwell> that bisect behavior also then results in some stupid tiny amount being left in the wallet often.
255 2016-04-08T08:26:11  <gmaxwell> but yes, it was just an aside comment for new APIs.
256 2016-04-08T08:27:58  *** frankenmint has quit IRC
257 2016-04-08T08:40:15  *** cjcj has quit IRC
258 2016-04-08T08:44:01  *** Alopex has quit IRC
259 2016-04-08T08:45:07  *** Alopex has joined #bitcoin-core-dev
260 2016-04-08T08:58:10  *** cjcj has joined #bitcoin-core-dev
261 2016-04-08T09:07:32  *** JackH has quit IRC
262 2016-04-08T09:11:12  <jonasschnelli> Hmm... doesn't this lead to wrong fee calculation: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1960
263 2016-04-08T09:11:23  <jonasschnelli> (adding inputs after CreateTransaction)
264 2016-04-08T09:11:43  <jonasschnelli> ping TheBlueMatt
265 2016-04-08T09:13:33  *** AaronvanW has joined #bitcoin-core-dev
266 2016-04-08T09:13:49  *** jtimon has joined #bitcoin-core-dev
267 2016-04-08T09:20:53  <jonasschnelli> Never-mind! It's correct.
268 2016-04-08T09:23:15  *** p15x has quit IRC
269 2016-04-08T09:23:54  *** arowser has quit IRC
270 2016-04-08T09:24:21  *** arowser has joined #bitcoin-core-dev
271 2016-04-08T09:49:17  *** gevs has joined #bitcoin-core-dev
272 2016-04-08T09:52:12  *** paveljanik has quit IRC
273 2016-04-08T09:55:12  *** fengling has quit IRC
274 2016-04-08T10:02:40  *** randy-waterhouse has joined #bitcoin-core-dev
275 2016-04-08T10:46:03  *** shangzhou has joined #bitcoin-core-dev
276 2016-04-08T10:53:08  *** spikeheadon has quit IRC
277 2016-04-08T11:13:33  *** johnwhitton has quit IRC
278 2016-04-08T11:22:11  *** d_t has joined #bitcoin-core-dev
279 2016-04-08T11:36:37  *** randy-waterhouse has quit IRC
280 2016-04-08T11:51:10  *** laurentmt has joined #bitcoin-core-dev
281 2016-04-08T11:57:07  *** fuc has joined #bitcoin-core-dev
282 2016-04-08T12:02:05  *** dermoth_ has joined #bitcoin-core-dev
283 2016-04-08T12:02:31  *** dermoth has quit IRC
284 2016-04-08T12:02:33  *** dermoth_ is now known as dermoth
285 2016-04-08T12:04:56  *** laurentmt has quit IRC
286 2016-04-08T12:13:19  <GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5851915a006a...232592a71f02
287 2016-04-08T12:13:19  <GitHub69> bitcoin/master eda3d92 mruddy: Net: Add IPv6 Link-Local Address Support
288 2016-04-08T12:13:19  <GitHub69> bitcoin/master 232592a Wladimir J. van der Laan: Merge #7570: Net: Add IPv6 Link-Local Address Support...
289 2016-04-08T12:13:22  <GitHub33> [bitcoin] laanwj closed pull request #7570: Net: Add IPv6 Link-Local Address Support (master...ipv6-link-local) https://github.com/bitcoin/bitcoin/pull/7570
290 2016-04-08T12:18:14  <GitHub179> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/232592a71f02...0afac87e8173
291 2016-04-08T12:18:15  <GitHub179> bitcoin/master e4ba9f6 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
292 2016-04-08T12:18:16  <GitHub179> bitcoin/master 5cb1d8a Suhas Daftuar: Tests: move get_bip9_status to util.py
293 2016-04-08T12:18:16  <GitHub179> bitcoin/master da5fdbb Suhas Daftuar: Test relay of version 2 transactions
294 2016-04-08T12:18:24  <GitHub186> [bitcoin] laanwj closed pull request #7835: Version 2 transactions remain non-standard until CSV activates (master...CSV-relay-after-softfork) https://github.com/bitcoin/bitcoin/pull/7835
295 2016-04-08T12:22:38  <GitHub78> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/46898e7e942b4e04021aac3724eb4f2ec4cf567b
296 2016-04-08T12:22:38  <GitHub78> bitcoin/0.12 46898e7 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
297 2016-04-08T12:26:07  <GitHub35> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/465d30915cd3c1634b32f942c1faae32967e9805
298 2016-04-08T12:26:07  <GitHub35> bitcoin/0.12 465d309 Wladimir J. van der Laan: doc: update release notes for #7835
299 2016-04-08T12:26:39  <wumpus>  * [new tag]         v0.12.1rc2 -> v0.12.1rc2
300 2016-04-08T12:28:53  *** fuc is now known as MrHodl
301 2016-04-08T12:34:40  *** frankenmint has joined #bitcoin-core-dev
302 2016-04-08T12:38:02  *** Alopex has quit IRC
303 2016-04-08T12:39:07  *** Alopex has joined #bitcoin-core-dev
304 2016-04-08T12:41:11  <michagogo> wumpus: script running, should push sigs shortly
305 2016-04-08T12:41:19  <wumpus> thanks!
306 2016-04-08T12:41:38  <michagogo> If the previous PR is still around it'll just update that (and confuse the script), otherwise there'll be a new one
307 2016-04-08T12:41:43  <MarcoFalke> Has anyone run the test suite on 0.12 yet?
308 2016-04-08T12:42:31  <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)
309 2016-04-08T12:44:24  <GitHub17> [bitcoin] dragongem45 opened pull request #7839: Expose information on whether transaction relayed is enabled in getne… (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7839
310 2016-04-08T12:45:04  *** Amnez777 has quit IRC
311 2016-04-08T12:45:34  *** mesmer_ has quit IRC
312 2016-04-08T12:46:03  *** mesmer_ has joined #bitcoin-core-dev
313 2016-04-08T12:46:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
314 2016-04-08T12:48:19  *** Amnez777 has joined #bitcoin-core-dev
315 2016-04-08T12:48:58  <MarcoFalke> Is there a difference between `int(unsigned(1))` and `static_cast<int>(unsigned(1))`?
316 2016-04-08T12:49:32  *** rubensayshi has quit IRC
317 2016-04-08T12:53:01  <sipa> MarcoFalke: no, both will return the same int
318 2016-04-08T12:53:16  <sipa> MarcoFalke: the first is weird C, the second is weird C++ :)
319 2016-04-08T12:55:24  <MarcoFalke> but they are different from `(int) ((unsigned) (1))`?
320 2016-04-08T12:55:38  <MarcoFalke> Assuming int and unsigned are any primitive type.
321 2016-04-08T12:56:59  <sipa> TYPE(VAL) is only valid in C++
322 2016-04-08T12:57:09  <sipa> in C you have to use (TYPE)VAL
323 2016-04-08T12:57:35  <sipa> int(5) is technically invoking the C++ constructor for int, with argument 5
324 2016-04-08T12:57:42  *** JackH has joined #bitcoin-core-dev
325 2016-04-08T12:57:43  <sipa> (int)5 is a C cast from 5 to int
326 2016-04-08T12:57:54  <sipa> static_cast<int>(5) is a C++ cast from 5 to int
327 2016-04-08T12:58:17  <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)
328 2016-04-08T12:58:50  <MarcoFalke> You can put (unsigned int) into braces and it should work, I think
329 2016-04-08T12:58:59  <wumpus> yes but that's just a C cast then
330 2016-04-08T12:59:45  <MarcoFalke> Ok, I was wondering what is preferred. E.g. static_cast<int>(nSize) or int(nSize)
331 2016-04-08T12:59:50  <MarcoFalke> re: negative fee rates
332 2016-04-08T12:59:58  <sipa> the first
333 2016-04-08T13:00:24  <MarcoFalke> so it's clear that a cast is happening?
334 2016-04-08T13:00:50  <sipa> the latter is C style, and its behaviour is a bit unpredictable
335 2016-04-08T13:01:03  <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
336 2016-04-08T13:01:19  <sipa> MarcoFalke: see point 1 here: http://en.cppreference.com/w/cpp/language/explicit_cast
337 2016-04-08T13:02:43  <wumpus> but yes in C++ using a C++ cast is probably best
338 2016-04-08T13:02:58  <wumpus> isn't int(X) c++ syntax too, though?
339 2016-04-08T13:03:10  <wumpus> in C, int doesn't have a constructor
340 2016-04-08T13:03:23  <sipa> int(X) is C++, yes
341 2016-04-08T13:03:23  <wumpus> you could only do (int)X
342 2016-04-08T13:03:28  <sipa> but it's not a cast :)
343 2016-04-08T13:03:48  <sipa> ... semantics, though
344 2016-04-08T13:03:51  <wumpus> what is the difference in practice?
345 2016-04-08T13:04:02  <wumpus> (for int, for other objects it probably invokes different methods)
346 2016-04-08T13:04:18  <sipa> ok, i learned today:
347 2016-04-08T13:04:19  <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.
348 2016-04-08T13:04:42  <wumpus> ah, that makes sense
349 2016-04-08T13:04:44  <sipa> so it's just extra C++ syntax equivalent to a C cast, with the same magic behaviour
350 2016-04-08T13:11:34  *** Luke-Jr has quit IRC
351 2016-04-08T13:16:33  *** Giszmo has joined #bitcoin-core-dev
352 2016-04-08T13:17:34  *** MarcoFalke has quit IRC
353 2016-04-08T13:18:46  *** MarcoFalke has joined #bitcoin-core-dev
354 2016-04-08T13:22:42  *** laurentmt has joined #bitcoin-core-dev
355 2016-04-08T13:26:33  <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
356 2016-04-08T13:26:55  <wumpus> what is sent to /dev/null and what to the log file?
357 2016-04-08T13:30:03  <wumpus> (my guess is everything goes to /dev/null and the second > is ignored, but I just don't know the syntax)
358 2016-04-08T13:30:29  <helo> everything ends up in /var/cache/gitian/upgrade.log (out and err)
359 2016-04-08T13:30:43  <wumpus> then what does the /dev/null do?
360 2016-04-08T13:30:55  *** laurentmt has quit IRC
361 2016-04-08T13:31:07  <sipa> wumpus: i believe i know the syntax, and that >/dev/null is redundant
362 2016-04-08T13:31:08  <helo> nothing
363 2016-04-08T13:31:16  <wumpus> okay
364 2016-04-08T13:32:14  <sipa> just tested it
365 2016-04-08T13:32:19  <sipa> (echo "stdout"; echo "stderr" >&2) >/dev/null >file 2>&1
366 2016-04-08T13:32:25  <sipa> writes both stdout and stderr to file
367 2016-04-08T13:33:04  <wumpus> awesome, thanks
368 2016-04-08T13:33:50  *** frankenmint has quit IRC
369 2016-04-08T13:38:13  <MarcoFalke> wumpus, do you really want to assert(int(nSize)>0)? nSize must represent a size of some GB (~ 1e9 GB, I think)...
370 2016-04-08T13:39:10  <wumpus> should be >=0 I think?
371 2016-04-08T13:39:29  <GitHub164> [bitcoin] sipa opened pull request #7840: Split and optimize inv queues and improve mempool privacy (master...splitinvtxblock) https://github.com/bitcoin/bitcoin/pull/7840
372 2016-04-08T13:40:01  <wumpus> but yes, such an assertion makes sense, to make sure the number is within the right range
373 2016-04-08T13:41:13  <wumpus> I don't think it'll ever trigger but better be safe than sorry
374 2016-04-08T13:42:06  <MarcoFalke> You don't want to have some code to be triggered by p2p which will cause the assert to fail ...
375 2016-04-08T13:42:25  <MarcoFalke> And remotly shut down any node
376 2016-04-08T13:42:36  <wumpus> that may be preferrable to the alternative, whatever happens with the big negative fee
377 2016-04-08T13:42:57  <MarcoFalke> if(nSize<0)nSize=max_nr
378 2016-04-08T13:43:01  <MarcoFalke> what about this?
379 2016-04-08T13:43:39  <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
380 2016-04-08T13:43:50  <MarcoFalke> ok
381 2016-04-08T13:44:12  <wumpus> it's a bug in our code if a size of ~1e9 GB reaches the fee rate function
382 2016-04-08T13:46:48  <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.
383 2016-04-08T13:47:08  <wumpus> well it overflows the integer range
384 2016-04-08T13:47:22  <wumpus> how would you handle that?
385 2016-04-08T13:47:22  <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..
386 2016-04-08T13:47:25  <helo> should data type validity be ensured during deserialization?
387 2016-04-08T13:47:40  *** frankenmint has joined #bitcoin-core-dev
388 2016-04-08T13:48:40  <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
389 2016-04-08T13:48:53  <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.
390 2016-04-08T13:49:22  <MarcoFalke> Will add the assert and the doc
391 2016-04-08T13:49:28  <MarcoFalke> Hopefully everyone is happy then
392 2016-04-08T13:49:32  <wumpus> as fee rates are not used to address into arrays this will probably never result in exploitable scenarios  or memory crashes
393 2016-04-08T13:50:00  <morcos> Yeah all I'm trying to suggest is that we make our assumptions explicit, sorry I probably didn't state that clearly
394 2016-04-08T13:50:04  <morcos> so sounds good
395 2016-04-08T13:51:03  <wumpus> the point is that a size_t can be larger than std::numeric_limits<int64_t>::max()  on most platforms
396 2016-04-08T13:51:20  <sipa> use ptrdiff_t *ducks*
397 2016-04-08T13:51:23  <wumpus> so before the cast it makes sense to check that the value is <= that
398 2016-04-08T13:51:50  <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
399 2016-04-08T13:52:09  <wumpus> sipa: right, that would just move the issue to the interface :)
400 2016-04-08T13:53:16  <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 :)
401 2016-04-08T13:53:40  <GitHub19> [bitcoin] dragongem45 closed pull request #7839: Expose information on whether transaction relayed is enabled in getne… (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7839
402 2016-04-08T13:55:56  *** molly has quit IRC
403 2016-04-08T13:56:36  *** moli has joined #bitcoin-core-dev
404 2016-04-08T14:01:24  <wumpus> helo: probably, as the deserializer has knowledge of the types involved
405 2016-04-08T14:06:47  *** treehug88 has joined #bitcoin-core-dev
406 2016-04-08T14:08:09  *** lclc has left #bitcoin-core-dev
407 2016-04-08T14:08:15  *** lclc has joined #bitcoin-core-dev
408 2016-04-08T14:08:45  <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
409 2016-04-08T14:09:35  <wumpus> shit, just wiped the gitian output again by starting before I copied out the executables
410 2016-04-08T14:18:02  <GitHub24> [bitcoin] dragongem45 opened pull request #7841: Expose information on whether transaction relayed is enabled in getnetwork (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7841
411 2016-04-08T14:38:11  <morcos> sdaftuar: wumpus: i got a failure of bip68-sequence.py in 0.12.1rc2 .  but its intermittant.  looking into it.
412 2016-04-08T14:39:11  *** laurentmt has joined #bitcoin-core-dev
413 2016-04-08T14:49:55  *** cryptapus_afk is now known as cryptapus
414 2016-04-08T14:50:26  *** cryptapus is now known as cryptapus_
415 2016-04-08T14:50:34  *** cryptapus_ is now known as cryptapus__
416 2016-04-08T14:50:38  *** laurentmt has quit IRC
417 2016-04-08T14:50:41  *** cryptapus__ is now known as cryptapus
418 2016-04-08T14:50:54  <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
419 2016-04-08T14:52:38  *** bsm1175321 has joined #bitcoin-core-dev
420 2016-04-08T14:52:59  *** laurentmt has joined #bitcoin-core-dev
421 2016-04-08T14:53:02  *** bsm1175321 is now known as bsm117532
422 2016-04-08T14:53:56  *** MarcoFalke has quit IRC
423 2016-04-08T14:54:21  *** MarcoFalke has joined #bitcoin-core-dev
424 2016-04-08T14:56:10  * MarcoFalke Should buy more ram so gitian can run while working
425 2016-04-08T15:00:35  <morcos> yes thats the problem, i was confused b/c there are two cache directories.  one in pull-tester and one in rpc-tests
426 2016-04-08T15:00:55  <morcos> would it make sense for make clean to wipe out the cache directories?
427 2016-04-08T15:01:11  *** laurentmt has quit IRC
428 2016-04-08T15:07:23  <morcos> jonasschnelli: oops forgot to ping you.  i'm here.
429 2016-04-08T15:17:46  *** laurentmt has joined #bitcoin-core-dev
430 2016-04-08T15:17:54  *** laurentmt has quit IRC
431 2016-04-08T15:18:11  *** laurentmt has joined #bitcoin-core-dev
432 2016-04-08T15:28:06  *** Chris_Stewart_5 has quit IRC
433 2016-04-08T15:31:26  *** yoghur114 has joined #bitcoin-core-dev
434 2016-04-08T15:33:53  *** yoghur114 has quit IRC
435 2016-04-08T15:42:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
436 2016-04-08T15:43:30  *** abritoid has quit IRC
437 2016-04-08T15:48:35  <wumpus> morcos: so removing the cache made the problem go away?
438 2016-04-08T16:02:00  *** laurentmt has quit IRC
439 2016-04-08T16:03:26  *** paveljanik has joined #bitcoin-core-dev
440 2016-04-08T16:03:43  *** paveljanik has joined #bitcoin-core-dev
441 2016-04-08T16:07:27  <morcos> wumpus: yep.  it works fine with a fresh cache.
442 2016-04-08T16:07:40  <morcos> it makes sense that the old cache wouldn't work
443 2016-04-08T16:07:41  <wumpus> phew!
444 2016-04-08T16:25:01  *** d_t has quit IRC
445 2016-04-08T16:41:12  <btcdrak> why are gitian builds so slow in comparison to building on a non VM using same number of cores to compile with?
446 2016-04-08T16:43:07  <MarcoFalke> depends take the longest time
447 2016-04-08T16:48:42  *** Thireus1 has joined #bitcoin-core-dev
448 2016-04-08T16:51:53  *** Thireus has quit IRC
449 2016-04-08T16:53:18  <sdaftuar> morcos: oops, thanks for figuring it out.  seems innocuous enough to not worry about fixing in 0.12.1?
450 2016-04-08T16:53:19  *** laurentmt has joined #bitcoin-core-dev
451 2016-04-08T16:58:47  <GitHub122> [bitcoin] paveljanik opened pull request #7842: RPC: do not print minping time in getpeerinfo when no ping received yet (master...20160408_getpeerinfo_no_ping_yet) https://github.com/bitcoin/bitcoin/pull/7842
452 2016-04-08T17:11:21  <instagibbs> during a reorg, when(if ever) does a node re-broadcast transactions that have re-entered the mempool
453 2016-04-08T17:21:44  <morcos> instagibbs: i assume it does not
454 2016-04-08T17:23:27  *** johnwhitton has joined #bitcoin-core-dev
455 2016-04-08T17:24:32  <instagibbs> matches up with my testing just making sure
456 2016-04-08T17:25:02  <instagibbs> python testing kind of breaks when that happens, since many times it checks to ensure that mempools are synced
457 2016-04-08T17:26:44  *** johnwhitton has quit IRC
458 2016-04-08T17:27:37  *** johnwhitton has joined #bitcoin-core-dev
459 2016-04-08T17:32:28  *** gevs has quit IRC
460 2016-04-08T17:47:17  <btcdrak> interesting. I just noticed Github has started verifying GPG signed commits if you give it your key https://i.imgur.com/MNIYMm0.png
461 2016-04-08T17:47:43  <sipa> btcdrak: yup, i uploaded mine
462 2016-04-08T17:47:56  <btcdrak> https://i.imgur.com/KWHyAxe.png
463 2016-04-08T17:47:59  <btcdrak> yeah that's cool.
464 2016-04-08T17:49:21  *** mesmer_ has quit IRC
465 2016-04-08T17:49:29  *** mesmer has joined #bitcoin-core-dev
466 2016-04-08T17:49:40  <sipa> drommels drommels en nog eens drommels
467 2016-04-08T17:49:56  *** jannes has quit IRC
468 2016-04-08T17:50:23  * btcdrak googles franticly
469 2016-04-08T17:50:40  <btcdrak> "devils devils and further rattling"
470 2016-04-08T17:51:39  * sipa curses at C++ globals initialization & destruction order
471 2016-04-08T18:01:11  *** arubi has quit IRC
472 2016-04-08T18:15:21  *** arubi has joined #bitcoin-core-dev
473 2016-04-08T18:15:27  *** d_t has joined #bitcoin-core-dev
474 2016-04-08T19:10:50  *** belcher has joined #bitcoin-core-dev
475 2016-04-08T19:25:45  <cfields_> gitian builders: 0.12.1rc2 signatures are pushed
476 2016-04-08T19:25:59  *** ThomasV has joined #bitcoin-core-dev
477 2016-04-08T19:26:25  <ThomasV> are there ongoing projects to implement a utxo merkle tree in bitcoind ?
478 2016-04-08T19:30:44  <ThomasV> btcdrak: you used to work on addrindex, is it still active?
479 2016-04-08T19:31:10  <btcdrak> yes
480 2016-04-08T19:31:31  <ThomasV> how does it work?
481 2016-04-08T19:31:37  <btcdrak> See my fork
482 2016-04-08T19:32:07  <sipa> ThomasV: you one that is committed to by the blockchain?
483 2016-04-08T19:32:12  <sipa> *mean
484 2016-04-08T19:32:58  <ThomasV> sipa: obviouly not.. you already told me that is not planned
485 2016-04-08T19:33:14  <sipa> then why do you need to be a merkle tree?
486 2016-04-08T19:33:28  <sipa> :)
487 2016-04-08T19:34:11  <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)
488 2016-04-08T19:34:40  <sipa> so there could be future calls that query and produce proofs about it
489 2016-04-08T19:34:44  *** AtashiCon has quit IRC
490 2016-04-08T19:34:56  *** AtashiCon has joined #bitcoin-core-dev
491 2016-04-08T19:35:23  <ThomasV> sipa: what kind of proofs do you mean?
492 2016-04-08T19:35:47  <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
493 2016-04-08T19:36:12  <ThomasV> sipa: long term I want to add versum to electrum servers
494 2016-04-08T19:36:17  <sipa> versum?
495 2016-04-08T19:36:22  <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
496 2016-04-08T19:36:37  <ThomasV> err https://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf
497 2016-04-08T19:36:57  <ThomasV> unless utxo commitments happen, of course
498 2016-04-08T19:37:28  <ThomasV> that's why I prefer a merkle tree
499 2016-04-08T19:37:35  <sipa> ok, i'll read it later
500 2016-04-08T19:39:40  <ThomasV> sipa: btw, why is it that you decided to index by txid ?
501 2016-04-08T19:40:20  <sipa> ThomasV: because that's what matters for validation
502 2016-04-08T19:41:13  <ThomasV> oh sure
503 2016-04-08T19:41:22  <sipa> constructing a merkle tree at least requires to have the data ordered by the lookup key
504 2016-04-08T19:41:32  <sipa> and we already have the utxo set ordered by txid
505 2016-04-08T19:42:50  <sipa> ThomasV: where are you based, btw?
506 2016-04-08T19:42:58  <ThomasV> in Berlin
507 2016-04-08T19:43:21  <ThomasV> btcdrak: which branch should I look at?
508 2016-04-08T19:44:14  <btcdrak> addrindex-0.12
509 2016-04-08T19:44:29  <btcdrak> also tagged and binaries built in releases tab
510 2016-04-08T19:46:29  <sipa> ThomasV: ah, i'm in stuttgart currently
511 2016-04-08T19:47:00  <ThomasV> sipa: permanently? I thought you were in zurich
512 2016-04-08T19:47:09  <sipa> ThomasV: no, for a few days
513 2016-04-08T19:47:14  <ThomasV> k
514 2016-04-08T19:47:18  *** lejitz has joined #bitcoin-core-dev
515 2016-04-08T19:50:34  * sipa 's geography of germany is not very good
516 2016-04-08T19:51:13  *** lejitz has quit IRC
517 2016-04-08T19:51:52  <GitHub61> [bitcoin] initaldk opened pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843
518 2016-04-08T19:52:41  *** Don_John has joined #bitcoin-core-dev
519 2016-04-08T19:53:37  *** Guyver2 has joined #bitcoin-core-dev
520 2016-04-08T20:04:03  <GitHub172> [bitcoin] sipa closed pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843
521 2016-04-08T20:19:59  *** treehug88 has quit IRC
522 2016-04-08T20:20:19  *** d_t has quit IRC
523 2016-04-08T20:29:38  <ThomasV> stuttgart is much closer to zurich than to berlin :)
524 2016-04-08T20:39:05  <ThomasV> time to watch spacex tv..
525 2016-04-08T20:49:40  *** d_t has joined #bitcoin-core-dev
526 2016-04-08T20:56:23  *** s-matthew-englis has joined #bitcoin-core-dev
527 2016-04-08T20:57:31  *** matthew_english has joined #bitcoin-core-dev
528 2016-04-08T20:57:34  *** Luke-Jr has joined #bitcoin-core-dev
529 2016-04-08T20:58:28  <matthew_english> hi paveljanik
530 2016-04-08T20:58:50  <paveljanik> matthew_english, Hi!
531 2016-04-08T20:59:05  <matthew_english> :)
532 2016-04-08T20:59:37  <matthew_english> so- do you think we might be able to figure out how to commit this silly change?
533 2016-04-08T20:59:48  <paveljanik> yup
534 2016-04-08T21:00:05  <paveljanik> please do again step by step what I wrote to you and lets pause in vi :-)
535 2016-04-08T21:00:06  <matthew_english> thank you for your help thus far also
536 2016-04-08T21:00:12  <matthew_english> ok coo
537 2016-04-08T21:00:15  <matthew_english> cool
538 2016-04-08T21:00:27  <matthew_english> so I'll delete the repo and reclone it- one moment...
539 2016-04-08T21:00:37  <paveljanik> yes
540 2016-04-08T21:00:40  <paveljanik> I'll do it here too
541 2016-04-08T21:00:55  <matthew_english> ok
542 2016-04-08T21:01:00  <matthew_english> i downloaded my own fork
543 2016-04-08T21:01:32  <matthew_english> alright
544 2016-04-08T21:01:36  <matthew_english> now I'm in vi
545 2016-04-08T21:01:53  <paveljanik> so you see two lines starting with pick, right?
546 2016-04-08T21:02:06  <matthew_english> righto
547 2016-04-08T21:02:10  * paveljanik is an Emacs user 8)
548 2016-04-08T21:02:20  <matthew_english> haha I'm a sublime user
549 2016-04-08T21:02:20  <paveljanik> so go to the second line
550 2016-04-08T21:02:21  <matthew_english> very lame
551 2016-04-08T21:02:22  <matthew_english> but
552 2016-04-08T21:02:26  <matthew_english> I want to start using emacs
553 2016-04-08T21:02:35  <matthew_english> ok
554 2016-04-08T21:02:42  <matthew_english> and must press 'i' isn't it?
555 2016-04-08T21:02:47  <paveljanik> push x to delete one character, repeat until there is no p i c k :-)
556 2016-04-08T21:03:02  <matthew_english> ok
557 2016-04-08T21:03:05  <matthew_english> done
558 2016-04-08T21:03:08  <paveljanik> then i and type squash or s, it is enough
559 2016-04-08T21:03:18  <paveljanik> so your first line reads pick something
560 2016-04-08T21:03:21  <paveljanik> second line s something
561 2016-04-08T21:03:32  <paveljanik> then you are ready to exit
562 2016-04-08T21:03:35  <matthew_english> ok cool
563 2016-04-08T21:03:36  <paveljanik> Esc : wq
564 2016-04-08T21:03:38  <matthew_english> the :q
565 2016-04-08T21:03:41  <matthew_english> ah ok cool
566 2016-04-08T21:03:46  <paveljanik> you know more than me :-)
567 2016-04-08T21:04:08  <paveljanik> This command instructs git to squash the second commit, to hide it
568 2016-04-08T21:04:21  <paveljanik> and now you'll see git commit message
569 2016-04-08T21:04:22  <matthew_english> to make the two into one
570 2016-04-08T21:04:24  <matthew_english> I guess
571 2016-04-08T21:04:31  <matthew_english> hmm
572 2016-04-08T21:04:35  <paveljanik> it contains both lines - from the first and also from the second squashed commit
573 2016-04-08T21:04:43  <paveljanik> right?
574 2016-04-08T21:04:49  <paveljanik> they are both the same in your case.
575 2016-04-08T21:04:59  <matthew_english> can I do 'git status' to see it?
576 2016-04-08T21:05:18  <paveljanik> you can use git log (in the other terminal, yes)
577 2016-04-08T21:05:27  <paveljanik> but you are in the middle of rebase...
578 2016-04-08T21:05:53  <matthew_english> I did git log
579 2016-04-08T21:05:56  <paveljanik> git log shows you commit messages
580 2016-04-08T21:05:58  <paveljanik> yes
581 2016-04-08T21:05:59  <matthew_english> but I don't see a commit message
582 2016-04-08T21:06:19  <matthew_english> it just says 'update polcy.cpp' twice
583 2016-04-08T21:06:43  *** matthew_english has left #bitcoin-core-dev
584 2016-04-08T21:06:47  <paveljanik> we will move to PM
585 2016-04-08T21:13:35  *** bsm117532 has quit IRC
586 2016-04-08T21:31:30  *** paveljanik has quit IRC
587 2016-04-08T21:37:30  <GitHub111> [bitcoin] sipa opened pull request #7846: Clean up lockorder data of destroyed mutexes (master...cleanlocks) https://github.com/bitcoin/bitcoin/pull/7846
588 2016-04-08T21:49:16  <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?'
589 2016-04-08T21:50:02  <sipa> EvalScript just evaluates, it doesn't check success conditions
590 2016-04-08T21:50:12  <sipa> so if it returns false, it means an error occurred
591 2016-04-08T21:50:24  <sipa> VerifyScript tests the success conditions for use in transactions
592 2016-04-08T21:50:33  <Chris_Stewart_5> because shouldn't the top of the stack indicate if the script exectuion was true/false?
593 2016-04-08T21:50:46  <sipa> yes, VerifyScript tests that
594 2016-04-08T21:51:45  *** kangx has quit IRC
595 2016-04-08T21:51:46  <Chris_Stewart_5> gotcha. Thanks for the clarification
596 2016-04-08T21:59:14  *** johnwhitton has quit IRC
597 2016-04-08T22:00:36  <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?
598 2016-04-08T22:01:15  *** xabbix has quit IRC
599 2016-04-08T22:02:21  *** xabbix has joined #bitcoin-core-dev
600 2016-04-08T22:02:21  *** xabbix has joined #bitcoin-core-dev
601 2016-04-08T22:16:57  *** laurentmt has quit IRC
602 2016-04-08T22:53:03  *** ThomasV has quit IRC
603 2016-04-08T22:55:17  *** ThomasV has joined #bitcoin-core-dev
604 2016-04-08T22:58:12  <GitHub158> [bitcoin] gmaxwell closed pull request #7805: Eliminate TX trickle bypass, sort TX invs for privacy and priority. (master...sorted_invs) https://github.com/bitcoin/bitcoin/pull/7805
605 2016-04-08T23:03:54  *** johnwhitton has joined #bitcoin-core-dev
606 2016-04-08T23:06:06  *** frankenmint has quit IRC
607 2016-04-08T23:10:00  *** river__ has quit IRC
608 2016-04-08T23:14:33  *** ThomasV has quit IRC
609 2016-04-08T23:16:31  *** Guyver2 has quit IRC
610 2016-04-08T23:31:06  *** Cory has quit IRC
611 2016-04-08T23:38:45  *** PRab has quit IRC
612 2016-04-08T23:42:10  *** PRab has joined #bitcoin-core-dev
613 2016-04-08T23:52:39  *** frankenmint has joined #bitcoin-core-dev
614 2016-04-08T23:54:16  *** cryptapus is now known as cryptapus_afk
615 2016-04-08T23:58:06  *** frankenmint has quit IRC