12016-04-08T00:09:28  *** Amnez777 has quit IRC
  22016-04-08T00:12:01  *** Amnez777 has joined #bitcoin-core-dev
  32016-04-08T00:26:11  *** fengling has joined #bitcoin-core-dev
  42016-04-08T00:30:36  *** fengling has quit IRC
  52016-04-08T00:31:19  *** johnwhitton has joined #bitcoin-core-dev
  62016-04-08T00:37:25  *** frankenmint has joined #bitcoin-core-dev
  72016-04-08T00:38:59  *** jtimon has quit IRC
  82016-04-08T00:43:08  *** frankenmint has quit IRC
  92016-04-08T00:45:20  *** fengling has joined #bitcoin-core-dev
 102016-04-08T00:48:35  *** OGF-US has left #bitcoin-core-dev
 112016-04-08T00:51:03  *** Ylbam has quit IRC
 122016-04-08T00:55:51  *** gevs has quit IRC
 132016-04-08T01:22:21  *** spikeheadon has quit IRC
 142016-04-08T01:30:06  *** dermoth has quit IRC
 152016-04-08T01:30:56  *** dermoth has joined #bitcoin-core-dev
 162016-04-08T01:41:57  *** belcher has quit IRC
 172016-04-08T02:00:25  *** dermoth has quit IRC
 182016-04-08T02:00:58  *** dermoth has joined #bitcoin-core-dev
 192016-04-08T02:15:13  *** Giszmo has quit IRC
 202016-04-08T02:15:58  *** Giszmo has joined #bitcoin-core-dev
 212016-04-08T02:19:01  *** Alopex has quit IRC
 222016-04-08T02:20:06  *** Alopex has joined #bitcoin-core-dev
 232016-04-08T02:34:10  *** davec has quit IRC
 242016-04-08T02:36:20  *** davec has joined #bitcoin-core-dev
 252016-04-08T02:44:50  *** xiangfu has joined #bitcoin-core-dev
 262016-04-08T02:47:34  *** afk11 has quit IRC
 272016-04-08T02:50:25  *** afk11 has joined #bitcoin-core-dev
 282016-04-08T02:53:29  *** arowser has joined #bitcoin-core-dev
 292016-04-08T02:54:30  *** laurentmt has joined #bitcoin-core-dev
 302016-04-08T02:54:30  *** laurentmt has quit IRC
 312016-04-08T03:01:55  *** zooko has quit IRC
 322016-04-08T03:05:06  *** PaulCape_ has joined #bitcoin-core-dev
 332016-04-08T03:07:34  *** PaulCapestany has quit IRC
 342016-04-08T03:31:33  *** xiangfu has quit IRC
 352016-04-08T03:35:22  *** Giszmo has quit IRC
 362016-04-08T04:03:01  *** Alopex has quit IRC
 372016-04-08T04:04:06  *** Alopex has joined #bitcoin-core-dev
 382016-04-08T04:35:02  *** Alopex has quit IRC
 392016-04-08T04:36:07  *** Alopex has joined #bitcoin-core-dev
 402016-04-08T05:04:42  *** Luke-Jr has quit IRC
 412016-04-08T05:14:16  *** fkhan_ has quit IRC
 422016-04-08T05:30:36  *** fengling has quit IRC
 432016-04-08T05:30:53  *** fkhan_ has joined #bitcoin-core-dev
 442016-04-08T05:40:01  *** Alopex has quit IRC
 452016-04-08T05:41:01  <gmaxwell>     "minping": 9223372036854.775,
 462016-04-08T05:41:06  *** Alopex has joined #bitcoin-core-dev
 472016-04-08T05:44:03  <gmaxwell> interestingly one is on an outbound tor peer, another is on an inbound local peer.
 482016-04-08T05:44:09  <gmaxwell> oh.. right this host is running core in valgrind.
 492016-04-08T05:47:17  *** frankenmint has joined #bitcoin-core-dev
 502016-04-08T05:49:53  *** Luke-Jr has joined #bitcoin-core-dev
 512016-04-08T05:49:58  *** frankenmint has quit IRC
 522016-04-08T05:51:02  *** frankenmint has joined #bitcoin-core-dev
 532016-04-08T05:56:01  *** Alopex has quit IRC
 542016-04-08T05:57:06  *** Alopex has joined #bitcoin-core-dev
 552016-04-08T06:00:08  *** dermoth has quit IRC
 562016-04-08T06:00:47  *** dermoth has joined #bitcoin-core-dev
 572016-04-08T06:04:08  *** Thireus has joined #bitcoin-core-dev
 582016-04-08T06:04:52  *** fengling has joined #bitcoin-core-dev
 592016-04-08T06:07:37  *** Ylbam has joined #bitcoin-core-dev
 602016-04-08T06:18:02  *** Alopex has quit IRC
 612016-04-08T06:19:07  *** Alopex has joined #bitcoin-core-dev
 622016-04-08T06:30:49  *** johnwhitton has quit IRC
 632016-04-08T06:35:17  *** johnwhitton has joined #bitcoin-core-dev
 642016-04-08T06:38:17  *** johnwhitton has quit IRC
 652016-04-08T06:38:41  *** johnwhitton has joined #bitcoin-core-dev
 662016-04-08T06:41:00  *** johnwhitton has joined #bitcoin-core-dev
 672016-04-08T06:43:08  *** johnwhitton has quit IRC
 682016-04-08T06:44:16  *** [Author] has quit IRC
 692016-04-08T06:44:39  <wumpus> gmaxwell: there used to be a problem where minping was not initialized
 702016-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
 712016-04-08T06:45:31  <michagogo> It went as far as building protobuf, but then failed when extracting boost
 722016-04-08T06:45:34  <wumpus> I managed to build all three - what's the issue?
 732016-04-08T06:46:13  <michagogo> Tons of error messages from tar, cannot mkdir/open: read-only file system o_O
 742016-04-08T06:46:26  <wumpus> gmaxwell: or is that std::numeric_limits<int64_t>::max()?
 752016-04-08T06:47:06  <wumpus> yes it is. Okay that means that there hasn't been a ping ever
 762016-04-08T06:51:41  *** spikeheadon has joined #bitcoin-core-dev
 772016-04-08T06:51:56  *** abritoid has joined #bitcoin-core-dev
 782016-04-08T06:53:25  *** [Author] has joined #bitcoin-core-dev
 792016-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'
 802016-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)
 812016-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)
 822016-04-08T06:57:55  <wumpus> in any case whatever the behavior it needs to be documented in 'help' of the RPC call
 832016-04-08T07:00:30  <wumpus> but hey, it's better than uninitialized memory, which it used to be before #6636
 842016-04-08T07:02:34  <paveljanik> what about using negative value instead?
 852016-04-08T07:04:39  <gmaxwell> then it probably sorts in the wrong position.
 862016-04-08T07:05:27  <paveljanik> if it is not excluded from the sort as evidently invalid value, yes.
 872016-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
 882016-04-08T07:05:46  <wumpus> I think sipa's 'null' makes most sense
 892016-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!'
 902016-04-08T07:11:40  <wumpus> do we have a way to make a node stop syncing at a certain block?
 912016-04-08T07:12:40  <wumpus> oh I guess syncing until tip and then -connect=0.0.0.0 will do the job
 922016-04-08T07:16:08  *** johnwhitton has joined #bitcoin-core-dev
 932016-04-08T07:16:18  <jonasschnelli> wumpus: I was also looking for this some time ago (for the UTXO set dump). I hardcoded something.
 942016-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
 952016-04-08T07:17:31  <wumpus> i'm also comparing utxo set dumps :)
 962016-04-08T07:18:41  <jonasschnelli> morcos: ping. Tell me when you have a couple of minutes to discuss the "new wallet" concerns.
 972016-04-08T07:19:13  <wumpus> so something like my 'label API' would be new wallet only?
 982016-04-08T07:20:20  <jonasschnelli> wumpus: Yes. I think it would be better.
 992016-04-08T07:20:33  *** johnwhitton has quit IRC
1002016-04-08T07:20:37  <jonasschnelli> Because we don't need to take care about the account compatibility.
1012016-04-08T07:20:46  <wumpus> on the other hand it may give people a stepping stone to the new wallet
1022016-04-08T07:20:48  <wumpus> I agree
1032016-04-08T07:21:02  <jonasschnelli> But I'm fine with your PR for the old wallet.
1042016-04-08T07:21:24  *** johnwhitton has joined #bitcoin-core-dev
1052016-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).
1062016-04-08T07:21:52  <jonasschnelli> Peer reviews is really something that improves the quality.
1072016-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.
1082016-04-08T07:23:15  <jonasschnelli> Merge ready could be: 1) remove accounts, 2) switch from BDB to LogDB, 3) simplify update logic
1092016-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
1102016-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.
1112016-04-08T07:26:15  <wumpus> with the understanding that it will likely just be disabled for the 0.13 release
1122016-04-08T07:26:31  <wumpus> or super-experimental
1132016-04-08T07:26:47  <wumpus> depending on where things are
1142016-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.
1152016-04-08T07:29:06  <jonasschnelli> Deploying it to the broad user base is something different.
1162016-04-08T07:29:17  <jonasschnelli> Could be in 0.14, 0.15, depending on the progress.
1172016-04-08T07:29:32  <wumpus> right
1182016-04-08T07:29:35  <jonasschnelli> If it turns out as a bad idea, we can always remove it without loosing anything.
1192016-04-08T07:29:46  <jonasschnelli> (before deployed)
1202016-04-08T07:29:54  <wumpus> agree
1212016-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?
1222016-04-08T07:34:22  <wumpus> jonasschnelli: hey what a good idea
1232016-04-08T07:34:59  <wumpus> yes that may be best, unless it kills the application in a logging flood of deadlock notifications
1242016-04-08T07:35:04  <michagogo> 10:11:40 <wumpus> do we have a way to make a node stop syncing at a certain block?
1252016-04-08T07:35:08  <wumpus> but that's not my experience
1262016-04-08T07:35:12  <michagogo> Does blacklisting do that?
1272016-04-08T07:35:31  <wumpus> michagogo: but you can only blacklist a block *after* you have it, or not?
1282016-04-08T07:35:40  <michagogo> wumpus: that's what I'm not sure about
1292016-04-08T07:36:08  <michagogo> If that doesn't work, it should be made the case that it does :P
1302016-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
1312016-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 ... :-)
1322016-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.
1332016-04-08T07:41:11  <wumpus> I think we should comment out the whole function until someone sorts out the problem
1342016-04-08T07:42:22  <wumpus> then when brining it back we can make the decision, should it crash or just report
1352016-04-08T07:42:36  <wumpus> but that's after we've fixed the non-sensical reports
1362016-04-08T07:43:48  <jonasschnelli> Agree
1372016-04-08T07:44:33  <wumpus> even having it as special autoconf option is not useful as long as it misfires
1382016-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
1392016-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
1402016-04-08T07:53:56  <jonasschnelli> why the heck does "sendtoaddress" has a "comment" and a "comment-to" argument? Isn't this very confusing?
1412016-04-08T07:54:22  <Luke-Jr> it's all confusing
1422016-04-08T07:54:24  <wumpus> yes
1432016-04-08T07:54:26  <wumpus> axe them
1442016-04-08T07:54:36  <Luke-Jr> should really just be one comment/label per address. simple and clean.
1452016-04-08T07:54:38  <sipa> it stores a comment on the address and a comment on the transaction, afaik :)
1462016-04-08T07:54:59  <jonasschnelli> hmm... I think we should only have comments for transactions.
1472016-04-08T07:55:23  <jonasschnelli> Doesn't labels for addresses as well as a "address book" implies address-resuse?
1482016-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)
1492016-04-08T07:55:38  <wumpus> no, not really, remember multiple addresses can have the same label jonasschnelli
1502016-04-08T07:55:45  <wumpus> label is just a way to group addresses
1512016-04-08T07:56:03  <jonasschnelli> wumpus: Ah. Right. That makes more sense.
1522016-04-08T07:56:09  <wumpus> 'all addresses I've sent to that belong to jonasschnelli'  etc
1532016-04-08T07:56:25  <wumpus> 'all addresses Ive used to receive from XYZ'
1542016-04-08T07:56:32  <jonasschnelli> So a send-command then requires a comment (wtx) and a label (for the to address)
1552016-04-08T07:56:44  <jonasschnelli> What about a label for the change-address? Not necessary i guess
1562016-04-08T07:56:53  <wumpus> in any case, please make the command accept a structure
1572016-04-08T07:57:00  <wumpus> so you can have optinoal arguments as well as extensibility
1582016-04-08T07:57:01  <Luke-Jr> jonasschnelli: I don't see value in association with a wtx rather than an address.
1592016-04-08T07:57:07  <wumpus> not the current positional hellscape
1602016-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).
1612016-04-08T07:57:46  <wumpus> we don't have to lock this down now if the API is extensible
1622016-04-08T07:57:50  <wumpus> yes please
1632016-04-08T07:57:51  <jonasschnelli> So each parameter has always a key
1642016-04-08T07:57:55  <wumpus> right
1652016-04-08T07:58:15  <jonasschnelli> Okay... and maybe also auto-detecting JSON object in bitcoin-cli to get rid of the static conversion table.
1662016-04-08T07:58:54  <wumpus> yes I think a RPC call to get the command line to JSON conversion table would make sense
1672016-04-08T07:59:32  <wumpus> although OTOH it's not a server concern, it's more like 'give me machine parsable docuentation'
1682016-04-08T08:00:32  <jonasschnelli> Okay.
1692016-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)
1702016-04-08T08:01:16  <sipa> i remember something like that
1712016-04-08T08:01:21  <sipa> even some existing standard
1722016-04-08T08:01:25  <wumpus> right
1732016-04-08T08:02:01  <wumpus> 'introspection' is the word
1742016-04-08T08:02:10  <jonasschnelli> But isn't the JSON conversion table something 100% on the client side?
1752016-04-08T08:02:17  <wumpus> https://github.com/bitcoin/bitcoin/issues/4157
1762016-04-08T08:02:19  <wumpus> bingo
1772016-04-08T08:02:25  * jonasschnelli looking...
1782016-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
1792016-04-08T08:02:49  <jonasschnelli> ah. Something like a WSDL
1802016-04-08T08:03:18  <wumpus> basically to help the client know what fields are expected, what types, etc, without having to hardcode this
1812016-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
1822016-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.
1832016-04-08T08:05:16  <wumpus> exactly
1842016-04-08T08:05:23  <jonasschnelli> Like a SOAP WSDL
1852016-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.
1862016-04-08T08:05:47  <wumpus> mostly-static, it can change based on server configuration (different wallets, no wallet, etc)
1872016-04-08T08:06:03  <jonasschnelli> Agree
1882016-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
1892016-04-08T08:06:21  <sipa> whenever you trigger a rpc type conversion error
1902016-04-08T08:06:23  <jonasschnelli> We could use /wallet for the new wallet commands... or wallet_command at the same root (/) endpoint
1912016-04-08T08:06:32  <jonasschnelli> sipa: +1
1922016-04-08T08:06:39  <sipa> you get the new table
1932016-04-08T08:07:19  <wumpus> or add an optional header to the RPC request: Fail-if-conversion-table-hash-is-not: XXXXX
1942016-04-08T08:07:38  <wumpus> then on failure retrieve the new list and do the conversion and request again
1952016-04-08T08:08:34  <wumpus> jonasschnelli: yes, different endpoints is also possible, we've discussed this in the path for multi-wallet support
1962016-04-08T08:08:39  <wumpus> in the PAST
1972016-04-08T08:09:13  <wumpus> you'd have to rewrite the RPC server a bit though so you instance it multiple times
1982016-04-08T08:09:26  <jonasschnelli> Yes. Command prefixes would be much simpler.
1992016-04-08T08:09:31  *** p15x has joined #bitcoin-core-dev
2002016-04-08T08:09:39  <jonasschnelli> Also the Multiwallet would be trivial with RPC argument structures.
2012016-04-08T08:09:52  <jonasschnelli> Just pass a {"wallet" : "wallet1", ... }
2022016-04-08T08:10:03  <wumpus> you mean command prefixes such as 'wallet.getinfo' 'mempool.getinfo' etc
2032016-04-08T08:10:10  <jonasschnelli> If no wallet is defined, use the "default" wallet
2042016-04-08T08:10:14  <wumpus> that won't help multiple wallets of the same type, of course
2052016-04-08T08:10:27  <wumpus> I wouldn't like wallet_wumpus.getinfo etc
2062016-04-08T08:10:28  <wumpus> right
2072016-04-08T08:10:41  <sipa> use separate url for each wallet
2082016-04-08T08:10:47  * jonasschnelli likes the <dot>. syntax.
2092016-04-08T08:11:04  <jonasschnelli> url endpoints is non-trivial to implement.
2102016-04-08T08:11:06  <wumpus> does JSONRPC even allow dots in method names?
2112016-04-08T08:11:11  <wumpus> it's pretty trivial to implement jonasschnelli
2122016-04-08T08:11:15  <jonasschnelli> hmm.. good question. :)
2132016-04-08T08:11:28  <sipa> jonasschnelli: it means that different wallets with different api can be loaded simultaneously
2142016-04-08T08:11:29  <wumpus> we've done quite some work in making that possible already
2152016-04-08T08:11:46  <jonasschnelli> okay... need to look at this.
2162016-04-08T08:11:50  <wumpus> just means we need some refactors which we really want anyway
2172016-04-08T08:11:55  <jonasschnelli> sipa: can you explain: "different wallets with different api can be loaded simultaneously"?
2182016-04-08T08:12:12  <wumpus> yes, if they have different endpoints, they can co-exist without even noticiing each other
2192016-04-08T08:12:20  <wumpus> (assuming they won't touch the same files etc)
2202016-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
2212016-04-08T08:12:48  <jonasschnelli> something like /wallet/mywallet/getinfo and wallet/createnewwallet
2222016-04-08T08:13:13  <sipa> jonasschnelli: if they run on different urls, you get that for free
2232016-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
2242016-04-08T08:13:31  <jonasschnelli> okay.
2252016-04-08T08:13:50  <jonasschnelli> A /wallet endpoint makes sense for now I guess.
2262016-04-08T08:14:05  <jonasschnelli> Also for further process de-coupeling.
2272016-04-08T08:14:12  <jonasschnelli> (which is out of scope for now)
2282016-04-08T08:14:31  <wumpus> yes, URL separateion also brings that
2292016-04-08T08:14:32  <wumpus> good point
2302016-04-08T08:14:57  * gmaxwell reads things out of context
2312016-04-08T08:14:57  <gmaxwell> 01:11 < wumpus> it's pretty trivial to implement jonasschnelli
2322016-04-08T08:15:02  *** jannes has joined #bitcoin-core-dev
2332016-04-08T08:15:15  <jonasschnelli> gmaxwell: lol...
2342016-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
2352016-04-08T08:15:21  <wumpus> gmaxwell: hahahahah oops
2362016-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.
2372016-04-08T08:17:54  <gmaxwell> start adding data to the address field with delimiters that can't be in addresses.
2382016-04-08T08:17:57  * gmaxwell ducks
2392016-04-08T08:18:57  <jonasschnelli> gmaxwell: almost as good as "sendtoaddress-with-rfb" :-)
2402016-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".
2412016-04-08T08:19:11  <wumpus> or just encode all arguments into the address with a special prefix
2422016-04-08T08:19:34  <gmaxwell> wumpus: we have that api already, it's called 'sendrawtransaction' :)
2432016-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
2442016-04-08T08:20:28  <jonasschnelli> gmaxwell: "send all my funds, minus whatever fees are needed" is think  this is already possible npw
2452016-04-08T08:20:50  <jonasschnelli> gmaxwell: sendtoaddress(<adr>, getbalance(), subtractfeefromamount=true)
2462016-04-08T08:20:57  <wumpus> yes 'subtractfeefromamount'
2472016-04-08T08:21:16  <jonasschnelli> Which is an awesome feature IMO
2482016-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'
2492016-04-08T08:21:42  <wumpus> which should be possible with a better API
2502016-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)
2512016-04-08T08:23:41  <wumpus> haha yes I think I've done that once too
2522016-04-08T08:24:20  <wumpus> bisecting the number
2532016-04-08T08:25:01  <gmaxwell> oh when did that get added! I missed that.
2542016-04-08T08:25:22  <gmaxwell> that bisect behavior also then results in some stupid tiny amount being left in the wallet often.
2552016-04-08T08:26:11  <gmaxwell> but yes, it was just an aside comment for new APIs.
2562016-04-08T08:27:58  *** frankenmint has quit IRC
2572016-04-08T08:40:15  *** cjcj has quit IRC
2582016-04-08T08:44:01  *** Alopex has quit IRC
2592016-04-08T08:45:07  *** Alopex has joined #bitcoin-core-dev
2602016-04-08T08:58:10  *** cjcj has joined #bitcoin-core-dev
2612016-04-08T09:07:32  *** JackH has quit IRC
2622016-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
2632016-04-08T09:11:23  <jonasschnelli> (adding inputs after CreateTransaction)
2642016-04-08T09:11:43  <jonasschnelli> ping TheBlueMatt
2652016-04-08T09:13:33  *** AaronvanW has joined #bitcoin-core-dev
2662016-04-08T09:13:49  *** jtimon has joined #bitcoin-core-dev
2672016-04-08T09:20:53  <jonasschnelli> Never-mind! It's correct.
2682016-04-08T09:23:15  *** p15x has quit IRC
2692016-04-08T09:23:54  *** arowser has quit IRC
2702016-04-08T09:24:21  *** arowser has joined #bitcoin-core-dev
2712016-04-08T09:49:17  *** gevs has joined #bitcoin-core-dev
2722016-04-08T09:52:12  *** paveljanik has quit IRC
2732016-04-08T09:55:12  *** fengling has quit IRC
2742016-04-08T10:02:40  *** randy-waterhouse has joined #bitcoin-core-dev
2752016-04-08T10:46:03  *** shangzhou has joined #bitcoin-core-dev
2762016-04-08T10:53:08  *** spikeheadon has quit IRC
2772016-04-08T11:13:33  *** johnwhitton has quit IRC
2782016-04-08T11:22:11  *** d_t has joined #bitcoin-core-dev
2792016-04-08T11:36:37  *** randy-waterhouse has quit IRC
2802016-04-08T11:51:10  *** laurentmt has joined #bitcoin-core-dev
2812016-04-08T11:57:07  *** fuc has joined #bitcoin-core-dev
2822016-04-08T12:02:05  *** dermoth_ has joined #bitcoin-core-dev
2832016-04-08T12:02:31  *** dermoth has quit IRC
2842016-04-08T12:02:33  *** dermoth_ is now known as dermoth
2852016-04-08T12:04:56  *** laurentmt has quit IRC
2862016-04-08T12:13:19  <GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5851915a006a...232592a71f02
2872016-04-08T12:13:19  <GitHub69> bitcoin/master eda3d92 mruddy: Net: Add IPv6 Link-Local Address Support
2882016-04-08T12:13:19  <GitHub69> bitcoin/master 232592a Wladimir J. van der Laan: Merge #7570: Net: Add IPv6 Link-Local Address Support...
2892016-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
2902016-04-08T12:18:14  <GitHub179> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/232592a71f02...0afac87e8173
2912016-04-08T12:18:15  <GitHub179> bitcoin/master e4ba9f6 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
2922016-04-08T12:18:16  <GitHub179> bitcoin/master 5cb1d8a Suhas Daftuar: Tests: move get_bip9_status to util.py
2932016-04-08T12:18:16  <GitHub179> bitcoin/master da5fdbb Suhas Daftuar: Test relay of version 2 transactions
2942016-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
2952016-04-08T12:22:38  <GitHub78> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/46898e7e942b4e04021aac3724eb4f2ec4cf567b
2962016-04-08T12:22:38  <GitHub78> bitcoin/0.12 46898e7 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates...
2972016-04-08T12:26:07  <GitHub35> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/465d30915cd3c1634b32f942c1faae32967e9805
2982016-04-08T12:26:07  <GitHub35> bitcoin/0.12 465d309 Wladimir J. van der Laan: doc: update release notes for #7835
2992016-04-08T12:26:39  <wumpus>  * [new tag]         v0.12.1rc2 -> v0.12.1rc2
3002016-04-08T12:28:53  *** fuc is now known as MrHodl
3012016-04-08T12:34:40  *** frankenmint has joined #bitcoin-core-dev
3022016-04-08T12:38:02  *** Alopex has quit IRC
3032016-04-08T12:39:07  *** Alopex has joined #bitcoin-core-dev
3042016-04-08T12:41:11  <michagogo> wumpus: script running, should push sigs shortly
3052016-04-08T12:41:19  <wumpus> thanks!
3062016-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
3072016-04-08T12:41:43  <MarcoFalke> Has anyone run the test suite on 0.12 yet?
3082016-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)
3092016-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
3102016-04-08T12:45:04  *** Amnez777 has quit IRC
3112016-04-08T12:45:34  *** mesmer_ has quit IRC
3122016-04-08T12:46:03  *** mesmer_ has joined #bitcoin-core-dev
3132016-04-08T12:46:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3142016-04-08T12:48:19  *** Amnez777 has joined #bitcoin-core-dev
3152016-04-08T12:48:58  <MarcoFalke> Is there a difference between `int(unsigned(1))` and `static_cast<int>(unsigned(1))`?
3162016-04-08T12:49:32  *** rubensayshi has quit IRC
3172016-04-08T12:53:01  <sipa> MarcoFalke: no, both will return the same int
3182016-04-08T12:53:16  <sipa> MarcoFalke: the first is weird C, the second is weird C++ :)
3192016-04-08T12:55:24  <MarcoFalke> but they are different from `(int) ((unsigned) (1))`?
3202016-04-08T12:55:38  <MarcoFalke> Assuming int and unsigned are any primitive type.
3212016-04-08T12:56:59  <sipa> TYPE(VAL) is only valid in C++
3222016-04-08T12:57:09  <sipa> in C you have to use (TYPE)VAL
3232016-04-08T12:57:35  <sipa> int(5) is technically invoking the C++ constructor for int, with argument 5
3242016-04-08T12:57:42  *** JackH has joined #bitcoin-core-dev
3252016-04-08T12:57:43  <sipa> (int)5 is a C cast from 5 to int
3262016-04-08T12:57:54  <sipa> static_cast<int>(5) is a C++ cast from 5 to int
3272016-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)
3282016-04-08T12:58:50  <MarcoFalke> You can put (unsigned int) into braces and it should work, I think
3292016-04-08T12:58:59  <wumpus> yes but that's just a C cast then
3302016-04-08T12:59:45  <MarcoFalke> Ok, I was wondering what is preferred. E.g. static_cast<int>(nSize) or int(nSize)
3312016-04-08T12:59:50  <MarcoFalke> re: negative fee rates
3322016-04-08T12:59:58  <sipa> the first
3332016-04-08T13:00:24  <MarcoFalke> so it's clear that a cast is happening?
3342016-04-08T13:00:50  <sipa> the latter is C style, and its behaviour is a bit unpredictable
3352016-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
3362016-04-08T13:01:19  <sipa> MarcoFalke: see point 1 here: http://en.cppreference.com/w/cpp/language/explicit_cast
3372016-04-08T13:02:43  <wumpus> but yes in C++ using a C++ cast is probably best
3382016-04-08T13:02:58  <wumpus> isn't int(X) c++ syntax too, though?
3392016-04-08T13:03:10  <wumpus> in C, int doesn't have a constructor
3402016-04-08T13:03:23  <sipa> int(X) is C++, yes
3412016-04-08T13:03:23  <wumpus> you could only do (int)X
3422016-04-08T13:03:28  <sipa> but it's not a cast :)
3432016-04-08T13:03:48  <sipa> ... semantics, though
3442016-04-08T13:03:51  <wumpus> what is the difference in practice?
3452016-04-08T13:04:02  <wumpus> (for int, for other objects it probably invokes different methods)
3462016-04-08T13:04:18  <sipa> ok, i learned today:
3472016-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.
3482016-04-08T13:04:42  <wumpus> ah, that makes sense
3492016-04-08T13:04:44  <sipa> so it's just extra C++ syntax equivalent to a C cast, with the same magic behaviour
3502016-04-08T13:11:34  *** Luke-Jr has quit IRC
3512016-04-08T13:16:33  *** Giszmo has joined #bitcoin-core-dev
3522016-04-08T13:17:34  *** MarcoFalke has quit IRC
3532016-04-08T13:18:46  *** MarcoFalke has joined #bitcoin-core-dev
3542016-04-08T13:22:42  *** laurentmt has joined #bitcoin-core-dev
3552016-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
3562016-04-08T13:26:55  <wumpus> what is sent to /dev/null and what to the log file?
3572016-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)
3582016-04-08T13:30:29  <helo> everything ends up in /var/cache/gitian/upgrade.log (out and err)
3592016-04-08T13:30:43  <wumpus> then what does the /dev/null do?
3602016-04-08T13:30:55  *** laurentmt has quit IRC
3612016-04-08T13:31:07  <sipa> wumpus: i believe i know the syntax, and that >/dev/null is redundant
3622016-04-08T13:31:08  <helo> nothing
3632016-04-08T13:31:16  <wumpus> okay
3642016-04-08T13:32:14  <sipa> just tested it
3652016-04-08T13:32:19  <sipa> (echo "stdout"; echo "stderr" >&2) >/dev/null >file 2>&1
3662016-04-08T13:32:25  <sipa> writes both stdout and stderr to file
3672016-04-08T13:33:04  <wumpus> awesome, thanks
3682016-04-08T13:33:50  *** frankenmint has quit IRC
3692016-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)...
3702016-04-08T13:39:10  <wumpus> should be >=0 I think?
3712016-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
3722016-04-08T13:40:01  <wumpus> but yes, such an assertion makes sense, to make sure the number is within the right range
3732016-04-08T13:41:13  <wumpus> I don't think it'll ever trigger but better be safe than sorry
3742016-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 ...
3752016-04-08T13:42:25  <MarcoFalke> And remotly shut down any node
3762016-04-08T13:42:36  <wumpus> that may be preferrable to the alternative, whatever happens with the big negative fee
3772016-04-08T13:42:57  <MarcoFalke> if(nSize<0)nSize=max_nr
3782016-04-08T13:43:01  <MarcoFalke> what about this?
3792016-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
3802016-04-08T13:43:50  <MarcoFalke> ok
3812016-04-08T13:44:12  <wumpus> it's a bug in our code if a size of ~1e9 GB reaches the fee rate function
3822016-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.
3832016-04-08T13:47:08  <wumpus> well it overflows the integer range
3842016-04-08T13:47:22  <wumpus> how would you handle that?
3852016-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..
3862016-04-08T13:47:25  <helo> should data type validity be ensured during deserialization?
3872016-04-08T13:47:40  *** frankenmint has joined #bitcoin-core-dev
3882016-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
3892016-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.
3902016-04-08T13:49:22  <MarcoFalke> Will add the assert and the doc
3912016-04-08T13:49:28  <MarcoFalke> Hopefully everyone is happy then
3922016-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
3932016-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
3942016-04-08T13:50:04  <morcos> so sounds good
3952016-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
3962016-04-08T13:51:20  <sipa> use ptrdiff_t *ducks*
3972016-04-08T13:51:23  <wumpus> so before the cast it makes sense to check that the value is <= that
3982016-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
3992016-04-08T13:52:09  <wumpus> sipa: right, that would just move the issue to the interface :)
4002016-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 :)
4012016-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
4022016-04-08T13:55:56  *** molly has quit IRC
4032016-04-08T13:56:36  *** moli has joined #bitcoin-core-dev
4042016-04-08T14:01:24  <wumpus> helo: probably, as the deserializer has knowledge of the types involved
4052016-04-08T14:06:47  *** treehug88 has joined #bitcoin-core-dev
4062016-04-08T14:08:09  *** lclc has left #bitcoin-core-dev
4072016-04-08T14:08:15  *** lclc has joined #bitcoin-core-dev
4082016-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
4092016-04-08T14:09:35  <wumpus> shit, just wiped the gitian output again by starting before I copied out the executables
4102016-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
4112016-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.
4122016-04-08T14:39:11  *** laurentmt has joined #bitcoin-core-dev
4132016-04-08T14:49:55  *** cryptapus_afk is now known as cryptapus
4142016-04-08T14:50:26  *** cryptapus is now known as cryptapus_
4152016-04-08T14:50:34  *** cryptapus_ is now known as cryptapus__
4162016-04-08T14:50:38  *** laurentmt has quit IRC
4172016-04-08T14:50:41  *** cryptapus__ is now known as cryptapus
4182016-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
4192016-04-08T14:52:38  *** bsm1175321 has joined #bitcoin-core-dev
4202016-04-08T14:52:59  *** laurentmt has joined #bitcoin-core-dev
4212016-04-08T14:53:02  *** bsm1175321 is now known as bsm117532
4222016-04-08T14:53:56  *** MarcoFalke has quit IRC
4232016-04-08T14:54:21  *** MarcoFalke has joined #bitcoin-core-dev
4242016-04-08T14:56:10  * MarcoFalke Should buy more ram so gitian can run while working
4252016-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
4262016-04-08T15:00:55  <morcos> would it make sense for make clean to wipe out the cache directories?
4272016-04-08T15:01:11  *** laurentmt has quit IRC
4282016-04-08T15:07:23  <morcos> jonasschnelli: oops forgot to ping you.  i'm here.
4292016-04-08T15:17:46  *** laurentmt has joined #bitcoin-core-dev
4302016-04-08T15:17:54  *** laurentmt has quit IRC
4312016-04-08T15:18:11  *** laurentmt has joined #bitcoin-core-dev
4322016-04-08T15:28:06  *** Chris_Stewart_5 has quit IRC
4332016-04-08T15:31:26  *** yoghur114 has joined #bitcoin-core-dev
4342016-04-08T15:33:53  *** yoghur114 has quit IRC
4352016-04-08T15:42:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4362016-04-08T15:43:30  *** abritoid has quit IRC
4372016-04-08T15:48:35  <wumpus> morcos: so removing the cache made the problem go away?
4382016-04-08T16:02:00  *** laurentmt has quit IRC
4392016-04-08T16:03:26  *** paveljanik has joined #bitcoin-core-dev
4402016-04-08T16:03:43  *** paveljanik has joined #bitcoin-core-dev
4412016-04-08T16:07:27  <morcos> wumpus: yep.  it works fine with a fresh cache.
4422016-04-08T16:07:40  <morcos> it makes sense that the old cache wouldn't work
4432016-04-08T16:07:41  <wumpus> phew!
4442016-04-08T16:25:01  *** d_t has quit IRC
4452016-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?
4462016-04-08T16:43:07  <MarcoFalke> depends take the longest time
4472016-04-08T16:48:42  *** Thireus1 has joined #bitcoin-core-dev
4482016-04-08T16:51:53  *** Thireus has quit IRC
4492016-04-08T16:53:18  <sdaftuar> morcos: oops, thanks for figuring it out.  seems innocuous enough to not worry about fixing in 0.12.1?
4502016-04-08T16:53:19  *** laurentmt has joined #bitcoin-core-dev
4512016-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
4522016-04-08T17:11:21  <instagibbs> during a reorg, when(if ever) does a node re-broadcast transactions that have re-entered the mempool
4532016-04-08T17:21:44  <morcos> instagibbs: i assume it does not
4542016-04-08T17:23:27  *** johnwhitton has joined #bitcoin-core-dev
4552016-04-08T17:24:32  <instagibbs> matches up with my testing just making sure
4562016-04-08T17:25:02  <instagibbs> python testing kind of breaks when that happens, since many times it checks to ensure that mempools are synced
4572016-04-08T17:26:44  *** johnwhitton has quit IRC
4582016-04-08T17:27:37  *** johnwhitton has joined #bitcoin-core-dev
4592016-04-08T17:32:28  *** gevs has quit IRC
4602016-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
4612016-04-08T17:47:43  <sipa> btcdrak: yup, i uploaded mine
4622016-04-08T17:47:56  <btcdrak> https://i.imgur.com/KWHyAxe.png
4632016-04-08T17:47:59  <btcdrak> yeah that's cool.
4642016-04-08T17:49:21  *** mesmer_ has quit IRC
4652016-04-08T17:49:29  *** mesmer has joined #bitcoin-core-dev
4662016-04-08T17:49:40  <sipa> drommels drommels en nog eens drommels
4672016-04-08T17:49:56  *** jannes has quit IRC
4682016-04-08T17:50:23  * btcdrak googles franticly
4692016-04-08T17:50:40  <btcdrak> "devils devils and further rattling"
4702016-04-08T17:51:39  * sipa curses at C++ globals initialization & destruction order
4712016-04-08T18:01:11  *** arubi has quit IRC
4722016-04-08T18:15:21  *** arubi has joined #bitcoin-core-dev
4732016-04-08T18:15:27  *** d_t has joined #bitcoin-core-dev
4742016-04-08T19:10:50  *** belcher has joined #bitcoin-core-dev
4752016-04-08T19:25:45  <cfields_> gitian builders: 0.12.1rc2 signatures are pushed
4762016-04-08T19:25:59  *** ThomasV has joined #bitcoin-core-dev
4772016-04-08T19:26:25  <ThomasV> are there ongoing projects to implement a utxo merkle tree in bitcoind ?
4782016-04-08T19:30:44  <ThomasV> btcdrak: you used to work on addrindex, is it still active?
4792016-04-08T19:31:10  <btcdrak> yes
4802016-04-08T19:31:31  <ThomasV> how does it work?
4812016-04-08T19:31:37  <btcdrak> See my fork
4822016-04-08T19:32:07  <sipa> ThomasV: you one that is committed to by the blockchain?
4832016-04-08T19:32:12  <sipa> *mean
4842016-04-08T19:32:58  <ThomasV> sipa: obviouly not.. you already told me that is not planned
4852016-04-08T19:33:14  <sipa> then why do you need to be a merkle tree?
4862016-04-08T19:33:28  <sipa> :)
4872016-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)
4882016-04-08T19:34:40  <sipa> so there could be future calls that query and produce proofs about it
4892016-04-08T19:34:44  *** AtashiCon has quit IRC
4902016-04-08T19:34:56  *** AtashiCon has joined #bitcoin-core-dev
4912016-04-08T19:35:23  <ThomasV> sipa: what kind of proofs do you mean?
4922016-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
4932016-04-08T19:36:12  <ThomasV> sipa: long term I want to add versum to electrum servers
4942016-04-08T19:36:17  <sipa> versum?
4952016-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
4962016-04-08T19:36:37  <ThomasV> err https://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf
4972016-04-08T19:36:57  <ThomasV> unless utxo commitments happen, of course
4982016-04-08T19:37:28  <ThomasV> that's why I prefer a merkle tree
4992016-04-08T19:37:35  <sipa> ok, i'll read it later
5002016-04-08T19:39:40  <ThomasV> sipa: btw, why is it that you decided to index by txid ?
5012016-04-08T19:40:20  <sipa> ThomasV: because that's what matters for validation
5022016-04-08T19:41:13  <ThomasV> oh sure
5032016-04-08T19:41:22  <sipa> constructing a merkle tree at least requires to have the data ordered by the lookup key
5042016-04-08T19:41:32  <sipa> and we already have the utxo set ordered by txid
5052016-04-08T19:42:50  <sipa> ThomasV: where are you based, btw?
5062016-04-08T19:42:58  <ThomasV> in Berlin
5072016-04-08T19:43:21  <ThomasV> btcdrak: which branch should I look at?
5082016-04-08T19:44:14  <btcdrak> addrindex-0.12
5092016-04-08T19:44:29  <btcdrak> also tagged and binaries built in releases tab
5102016-04-08T19:46:29  <sipa> ThomasV: ah, i'm in stuttgart currently
5112016-04-08T19:47:00  <ThomasV> sipa: permanently? I thought you were in zurich
5122016-04-08T19:47:09  <sipa> ThomasV: no, for a few days
5132016-04-08T19:47:14  <ThomasV> k
5142016-04-08T19:47:18  *** lejitz has joined #bitcoin-core-dev
5152016-04-08T19:50:34  * sipa 's geography of germany is not very good
5162016-04-08T19:51:13  *** lejitz has quit IRC
5172016-04-08T19:51:52  <GitHub61> [bitcoin] initaldk opened pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843
5182016-04-08T19:52:41  *** Don_John has joined #bitcoin-core-dev
5192016-04-08T19:53:37  *** Guyver2 has joined #bitcoin-core-dev
5202016-04-08T20:04:03  <GitHub172> [bitcoin] sipa closed pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843
5212016-04-08T20:19:59  *** treehug88 has quit IRC
5222016-04-08T20:20:19  *** d_t has quit IRC
5232016-04-08T20:29:38  <ThomasV> stuttgart is much closer to zurich than to berlin :)
5242016-04-08T20:39:05  <ThomasV> time to watch spacex tv..
5252016-04-08T20:49:40  *** d_t has joined #bitcoin-core-dev
5262016-04-08T20:56:23  *** s-matthew-englis has joined #bitcoin-core-dev
5272016-04-08T20:57:31  *** matthew_english has joined #bitcoin-core-dev
5282016-04-08T20:57:34  *** Luke-Jr has joined #bitcoin-core-dev
5292016-04-08T20:58:28  <matthew_english> hi paveljanik
5302016-04-08T20:58:50  <paveljanik> matthew_english, Hi!
5312016-04-08T20:59:05  <matthew_english> :)
5322016-04-08T20:59:37  <matthew_english> so- do you think we might be able to figure out how to commit this silly change?
5332016-04-08T20:59:48  <paveljanik> yup
5342016-04-08T21:00:05  <paveljanik> please do again step by step what I wrote to you and lets pause in vi :-)
5352016-04-08T21:00:06  <matthew_english> thank you for your help thus far also
5362016-04-08T21:00:12  <matthew_english> ok coo
5372016-04-08T21:00:15  <matthew_english> cool
5382016-04-08T21:00:27  <matthew_english> so I'll delete the repo and reclone it- one moment...
5392016-04-08T21:00:37  <paveljanik> yes
5402016-04-08T21:00:40  <paveljanik> I'll do it here too
5412016-04-08T21:00:55  <matthew_english> ok
5422016-04-08T21:01:00  <matthew_english> i downloaded my own fork
5432016-04-08T21:01:32  <matthew_english> alright
5442016-04-08T21:01:36  <matthew_english> now I'm in vi
5452016-04-08T21:01:53  <paveljanik> so you see two lines starting with pick, right?
5462016-04-08T21:02:06  <matthew_english> righto
5472016-04-08T21:02:10  * paveljanik is an Emacs user 8)
5482016-04-08T21:02:20  <matthew_english> haha I'm a sublime user
5492016-04-08T21:02:20  <paveljanik> so go to the second line
5502016-04-08T21:02:21  <matthew_english> very lame
5512016-04-08T21:02:22  <matthew_english> but
5522016-04-08T21:02:26  <matthew_english> I want to start using emacs
5532016-04-08T21:02:35  <matthew_english> ok
5542016-04-08T21:02:42  <matthew_english> and must press 'i' isn't it?
5552016-04-08T21:02:47  <paveljanik> push x to delete one character, repeat until there is no p i c k :-)
5562016-04-08T21:03:02  <matthew_english> ok
5572016-04-08T21:03:05  <matthew_english> done
5582016-04-08T21:03:08  <paveljanik> then i and type squash or s, it is enough
5592016-04-08T21:03:18  <paveljanik> so your first line reads pick something
5602016-04-08T21:03:21  <paveljanik> second line s something
5612016-04-08T21:03:32  <paveljanik> then you are ready to exit
5622016-04-08T21:03:35  <matthew_english> ok cool
5632016-04-08T21:03:36  <paveljanik> Esc : wq
5642016-04-08T21:03:38  <matthew_english> the :q
5652016-04-08T21:03:41  <matthew_english> ah ok cool
5662016-04-08T21:03:46  <paveljanik> you know more than me :-)
5672016-04-08T21:04:08  <paveljanik> This command instructs git to squash the second commit, to hide it
5682016-04-08T21:04:21  <paveljanik> and now you'll see git commit message
5692016-04-08T21:04:22  <matthew_english> to make the two into one
5702016-04-08T21:04:24  <matthew_english> I guess
5712016-04-08T21:04:31  <matthew_english> hmm
5722016-04-08T21:04:35  <paveljanik> it contains both lines - from the first and also from the second squashed commit
5732016-04-08T21:04:43  <paveljanik> right?
5742016-04-08T21:04:49  <paveljanik> they are both the same in your case.
5752016-04-08T21:04:59  <matthew_english> can I do 'git status' to see it?
5762016-04-08T21:05:18  <paveljanik> you can use git log (in the other terminal, yes)
5772016-04-08T21:05:27  <paveljanik> but you are in the middle of rebase...
5782016-04-08T21:05:53  <matthew_english> I did git log
5792016-04-08T21:05:56  <paveljanik> git log shows you commit messages
5802016-04-08T21:05:58  <paveljanik> yes
5812016-04-08T21:05:59  <matthew_english> but I don't see a commit message
5822016-04-08T21:06:19  <matthew_english> it just says 'update polcy.cpp' twice
5832016-04-08T21:06:43  *** matthew_english has left #bitcoin-core-dev
5842016-04-08T21:06:47  <paveljanik> we will move to PM
5852016-04-08T21:13:35  *** bsm117532 has quit IRC
5862016-04-08T21:31:30  *** paveljanik has quit IRC
5872016-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
5882016-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?'
5892016-04-08T21:50:02  <sipa> EvalScript just evaluates, it doesn't check success conditions
5902016-04-08T21:50:12  <sipa> so if it returns false, it means an error occurred
5912016-04-08T21:50:24  <sipa> VerifyScript tests the success conditions for use in transactions
5922016-04-08T21:50:33  <Chris_Stewart_5> because shouldn't the top of the stack indicate if the script exectuion was true/false?
5932016-04-08T21:50:46  <sipa> yes, VerifyScript tests that
5942016-04-08T21:51:45  *** kangx has quit IRC
5952016-04-08T21:51:46  <Chris_Stewart_5> gotcha. Thanks for the clarification
5962016-04-08T21:59:14  *** johnwhitton has quit IRC
5972016-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?
5982016-04-08T22:01:15  *** xabbix has quit IRC
5992016-04-08T22:02:21  *** xabbix has joined #bitcoin-core-dev
6002016-04-08T22:02:21  *** xabbix has joined #bitcoin-core-dev
6012016-04-08T22:16:57  *** laurentmt has quit IRC
6022016-04-08T22:53:03  *** ThomasV has quit IRC
6032016-04-08T22:55:17  *** ThomasV has joined #bitcoin-core-dev
6042016-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
6052016-04-08T23:03:54  *** johnwhitton has joined #bitcoin-core-dev
6062016-04-08T23:06:06  *** frankenmint has quit IRC
6072016-04-08T23:10:00  *** river__ has quit IRC
6082016-04-08T23:14:33  *** ThomasV has quit IRC
6092016-04-08T23:16:31  *** Guyver2 has quit IRC
6102016-04-08T23:31:06  *** Cory has quit IRC
6112016-04-08T23:38:45  *** PRab has quit IRC
6122016-04-08T23:42:10  *** PRab has joined #bitcoin-core-dev
6132016-04-08T23:52:39  *** frankenmint has joined #bitcoin-core-dev
6142016-04-08T23:54:16  *** cryptapus is now known as cryptapus_afk
6152016-04-08T23:58:06  *** frankenmint has quit IRC