1 2015-03-22 00:23:05 <roybadami> Am I the only one who when I first saw the new fee selection interface thought the 'Minimize' button would set the fee to the minimum?  I suggest something like 'Hide' might be better...
 2 2015-03-22 00:37:45 <Luke-Jr> roybadami: probably a good ide
 3 2015-03-22 00:37:48 <Luke-Jr> idea*
 4 2015-03-22 00:37:56 <Luke-Jr> do a PR against cfields's trivial branch?
 5 2015-03-22 00:58:25 <roybadami> I have no idea how to make changes that (presumably) would impact translations - hence commenting on IRC rather than a PR
 6 2015-03-22 01:00:13 <roybadami> (Also, what is cfield's trivial branch?)
 7 2015-03-22 01:25:01 <sipa> roybadami: he has a branch in which various trivial (no semantic change, small code impact) patvhes get merged
 8 2015-03-22 01:25:14 <sipa> and he occasionally sends a batch update upstream
 9 2015-03-22 01:40:27 <Luke-Jr> roybadami: nothing special to be done for translation impact
10 2015-03-22 01:40:48 <Luke-Jr> i18n is somewhat treated as a second thought still
11 2015-03-22 06:51:05 <fanquake> ;;blocks
12 2015-03-22 06:51:06 <gribble> 348653
13 2015-03-22 06:55:40 <tdryja> Hi I have a question about transaction ordering within a single block
14 2015-03-22 06:55:53 <tdryja> say there's outputs A, B, C
15 2015-03-22 06:55:58 <tdryja> and tx1, tx2
16 2015-03-22 06:56:00 <tdryja> tx1 is A -> B
17 2015-03-22 06:56:06 <tdryja> tx2 is B -> C
18 2015-03-22 06:56:26 <tdryja> tx2 can happen before tx1 is in a block
19 2015-03-22 06:56:42 <tdryja> but does tx2 need to appear after tx1 in the same block for that block to be valid?
20 2015-03-22 06:58:06 <Taek> not actually being familiar with the code
21 2015-03-22 06:58:08 <Taek> I believe so
22 2015-03-22 06:58:32 <tdryja> OK, it seems that way, but wasn't sure
23 2015-03-22 06:58:47 <tdryja> it would be pretty annoying to check otherwise
24 2015-03-22 06:59:19 <tdryja> if I saw tx2 first in the block, I'd have to search through the rest of the block to see if tx1 was in there
25 2015-03-22 06:59:32 <Taek> I don't think the algorithm would be that difficult. You could just store all of the missing outputs in a map
26 2015-03-22 06:59:39 <Taek> and see if it resolves by the end of the block
27 2015-03-22 06:59:50 <Taek> (I think, it's late I'm drunkish)
28 2015-03-22 06:59:59 <tdryja> yeah, wouldn't be that hard, but...
29 2015-03-22 07:00:09 <tdryja> if it all has to be in order it's really easy
30 2015-03-22 19:00:32 <cfields> jonasschnelli: any reason crypter.h/cpp wasn't moved to wallet/?
31 2015-03-22 19:00:52 <jonasschnelli> gmaxwell, regarding your concerns about "concurrent access" at https://github.com/bitcoin/bitcoin/pull/5934: do you see any difference between the current implementation and how it would be with the PR?
32 2015-03-22 19:01:14 <jonasschnelli> cfields, let me check. I thought it was used outside of the wallet scope
33 2015-03-22 19:01:32 <cfields> jonasschnelli: there's one unnecessary include, but no outside use atm
34 2015-03-22 19:02:01 <gmaxwell> jonasschnelli: I think at the moment by chance it's not actually possible to trigger a race. But the next user of that dynamic update API would quite possibly add a data race and not even realize it.  (disclaimer: if you changed anything since my comments, I haven't seen it yet).
35 2015-03-22 19:02:54 <gmaxwell> e.g. right now with your patch there is only one runtime updater of the list, and its hardly runtime since it happens at init.
36 2015-03-22 19:04:58 <gmaxwell> I had another concern that I'm not sure how to deal with. Right now callers can assume they can enumerate the set of available APIs once right at connect and they won't change (I think the python bitcoin json rpc stuff does this, so you can inspect the returned connection object to find out what RPCs it can perform.  Breaking that assumption isn't great, since you don't want every access to the membe
37 2015-03-22 19:05:05 <gmaxwell> rs of the returned object to require an extra RPC just to get the most current list for both performance reasons and because the multiple calls are not atomic so its impossible to make it race free.
38 2015-03-22 19:05:23 <jonasschnelli> gmaxwell, right. I think the rpc dispatch table with possibility to extend/change the table (as it is with PR 5934) is a intermediate state for a better solution.
39 2015-03-22 19:05:33 <gmaxwell> I didn't raise it because your actual dynamic use there isn't dynamic enough to expose that issue, but if any real runtime stuff were done with it that issue would be a concern.
40 2015-03-22 19:06:35 <jonasschnelli> gmaxwell, my long term plan for the rpc would be a signaling to possible attached modules when a new http (rpc based) connect comes in.
41 2015-03-22 19:06:53 <jonasschnelli> but this changeset would just be to large at the moment.
42 2015-03-22 19:07:31 <gmaxwell> (I don't actually understand the motivation for it being runtime instead of compile time; but I suspect that I'm likely to not like it philosophically on the same basis that I don't believe library software should have any change in functionality or api triggered by optional autoconf changes. ... but you're doing the work there some I'll make an effort to just trust your judgement on abstract meta-ma
43 2015-03-22 19:07:37 <gmaxwell> tters like that.)
44 2015-03-22 19:09:37 <jonasschnelli> gmaxwell, well, yes. It could (probably should) be linked during compile time. While thinking is also don't see a need for a flexible table. Maybe it was introduce because of a better code structure / better overview.
45 2015-03-22 19:09:53 <jonasschnelli> s/is/i
46 2015-03-22 19:10:32 <jonasschnelli> but as said. My main motivation is wallet "decoupling"/"modularization".
47 2015-03-22 19:11:04 <jonasschnelli> (so i can bring in a 2nd wallte implementation and a possibility to have both wallet in the same binary)
48 2015-03-22 19:11:21 <gmaxwell> yea, I withhold judgement there. :)
49 2015-03-22 19:11:43 <kanzure> you could do transparent rpc proxying to another process running the wallet
50 2015-03-22 19:13:17 <gmaxwell> (I mean, I have opinions on architecture and modularity, but I'm not doing that work so I don't want to stand in the way of anyone who is... I /try/ to reserve my standing in the way for things that I think harm the network, user security, or software reliability, not general codebase layout, modularity, formatting, etc. :) )
51 2015-03-22 19:14:37 <jonasschnelli> gmaxwell, your opinions and thought about archi./modularization are highly welcome (at least on my side) :)
52 2015-03-22 19:15:02 <jonasschnelli> kanzure, what about ZeroMQ?
53 2015-03-22 19:15:11 <kanzure> i don't think that's merged yet
54 2015-03-22 19:15:24 <jonasschnelli> cfields, yes. crypter.h/cpp should also go into wallet i think.
55 2015-03-22 19:15:35 <jonasschnelli> cfields, PR or do you move it?
56 2015-03-22 19:15:43 <cfields> jonasschnelli: ok, i'll pr right now.
57 2015-03-22 19:15:53 <gmaxwell> jonasschnelli: Yea, I realize you'd accept them, but we have lots of other people. So I try to refrain. I promise, I could personally manage to stop all progress if I spoke up on everything I have opinions about. :)
58 2015-03-22 19:15:55 <jonasschnelli> cfields, nice. Thanks. And sorry for missing that.
59 2015-03-22 19:15:56 <cfields> jonasschnelli: yea, i have it ready. just wanted to be sure there wasn't a reason not to
60 2015-03-22 19:16:15 <cfields> jonasschnelli: no worries. I did too in review :)
61 2015-03-22 19:16:25 <kanzure> gmaxwell: it is wrong to characterize opinion evaluation as progress halting
62 2015-03-22 19:18:05 <kanzure> jonasschnelli: when you rebased fundrawtransaction recently did you have a bunch of merge conflicts?
63 2015-03-22 19:18:20 <jonasschnelli> kanzure, yes. took me 1-2h!
64 2015-03-22 19:18:34 <kanzure> oh
65 2015-03-22 19:18:49 <jonasschnelli> kanzure, subtract fee from amount... did some changes in that region.
66 2015-03-22 19:19:14 <kanzure> i may need your assistance on my fundrawtransaction-watchonly branch soon, but will get back to you with specifics.
67 2015-03-22 19:19:26 <kanzure> last rebase went fine for me
68 2015-03-22 19:24:08 <jonasschnelli> kanzure, no worries. Just give a shout when i should take over or assist.
69 2015-03-22 19:25:34 <cfields> gmaxwell: for testing the openssl replacement in crypter for passphrase->privkey and encrypt/decrypt, any suggestions for obvious edge-cases other than zero-length and on/around blocksize boundaries?
70 2015-03-22 19:26:32 <gmaxwell> cfields: test incorrect passphrases both ones that cause AES padding decode failures (easy), and ones that don't (somewhat harder).
71 2015-03-22 19:28:03 <kanzure> multiple cycles of encrypt/decrypt? this isn't an edge case tho
72 2015-03-22 19:28:49 <jonasschnelli> hmm... i should once try to PR/commit my wallet encryption unit test: https://github.com/jonasschnelli/bitcoin/blob/2015/01/wallet/logdb/src/test/wallet_tests.cpp#L308
73 2015-03-22 19:28:58 <gmaxwell> kanzure: every piece of review to consider increases costs and slows development. I think I am largely able to distinguish cases where a failure to consider my opinion imposes greater or lesser risks. Given that we need to make progress and have finite resources... I'd rather minimize spending them on things I think are less critical.
74 2015-03-22 19:29:12 <cfields> gmaxwell: glad i asked, i didn't add any for those. thanks.
75 2015-03-22 19:33:35 <cfields> gmaxwell: i'll add those for sure. Most that I've added so far have been aimed at keeping compat with openssl. Anything beyond padding need special attention there?
76 2015-03-22 19:46:30 <cfields> only thing i can think of there is non-well-formed (wrong last byte or padded bytes not equal) padding, which afaik openssl has always refused to decrypt
77 2015-03-22 19:49:23 <luke-jr_> 
ACTION briefly ponders having Bitcoin Core GUI parse ~/.bash_history for /\bbitcoin-cli .*/ and appending that

78 2015-03-22 19:49:31 <luke-jr_> (no, I'm not seriously suggesting this)
79 2015-03-22 19:53:44 <jonasschnelli> luke-jr_, what if someone uses csh? :)
80 2015-03-22 19:53:54 <luke-jr_> csh? what's that? :P
81 2015-03-22 19:54:07 <jonasschnelli> or lets say non-bash shells?
82 2015-03-22 20:29:54 <gmaxwell> cfields: not that I'm aware of.
83 2015-03-22 20:38:21 <cfields> gmaxwell: ok thanks