1 2017-01-08 00:00:01	0|gmaxwell|phantomcircuit: so I've been thinking that I was being naughty every time I added one.
  2 2017-01-08 00:00:55	0|sipa|https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md
  3 2017-01-08 00:01:20	0|sipa|it gives an example that include a one-line unbraced indendented conditional
  4 2017-01-08 00:01:25	0|sipa|-den
  5 2017-01-08 00:01:32	0|BlueMatt|gmaxwell: I thoguht the same, but sipa corrected me
  6 2017-01-08 00:01:44	0|BlueMatt|oh, wait, prohibited on single line statements? no
  7 2017-01-08 00:01:46	0|BlueMatt|i knew that one
  8 2017-01-08 00:02:00	0|BlueMatt|i thought we had a style guide (or someone had a preference) for the open-brace /always/ being on the line after the if
  9 2017-01-08 00:03:18	0|gmaxwell|BlueMatt: thank you so much for commenting on #9484
 10 2017-01-08 00:03:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
 11 2017-01-08 00:03:58	0|gmaxwell|sipa: yea, I think that should be prohibited. But even if it's just permitted to not do that, I'd be much happier.
 12 2017-01-08 00:05:23	0|gmaxwell|I'm fine with "if (!something) return false;" too; but we've accepted patches that do nothing but add line breaks to code like that.
 13 2017-01-08 00:07:03	0|gmaxwell|but from working on software with that as a coding style, I recall that there was no way to get any of the existing formatters to enforce that rule.
 14 2017-01-08 00:11:04	0|gmaxwell|it would be neat if someone made a formater autoconfiguration tool that finds the formater settings that minimize the changes to your code base, then prompts you for all the settings that have no effect.
 15 2017-01-08 00:17:54	0|gmaxwell|hm actually clang-format has AllowShortIfStatementsOnASingleLine so it can do that, I was mistaken.
 16 2017-01-08 03:17:45	0|Chris_Stewart_5|It is possible to have a tx with no outputs right? It would just pay all inputs to miner fees?
 17 2017-01-08 03:18:06	0|luke-jr|Chris_Stewart_5: i don't think so
 18 2017-01-08 03:19:29	0|Chris_Stewart_5|Trying to get my generators right on #8469 it is important that they allow every possible value
 19 2017-01-08 03:19:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
 20 2017-01-08 03:22:14	0|gmaxwell|it is not possible.
 21 2017-01-08 03:22:28	0|gmaxwell|(I mean you can create such an encoding, but the transaction could never be valid.)
 22 2017-01-08 03:22:59	0|Chris_Stewart_5|gmaxwell: Valid in the policy sense?
 23 2017-01-08 03:23:11	0|gmaxwell|no, in the consensus rules sense.
 24 2017-01-08 03:23:22	0|gmaxwell|the word 'never' should have tipped you off. :)
 25 2017-01-08 03:25:01	0|Chris_Stewart_5|gmaxwell: I'm not sure i'm ready to believe you yet, why isn't it valid? Some where in validation.cpp there is a check for vout.size() > 0?
 26 2017-01-08 03:25:27	0|gmaxwell|yes.
 27 2017-01-08 03:25:55	0|Chris_Stewart_5|like you said, enocding/script wise it should be fine I think
 28 2017-01-08 03:26:37	0|Chris_Stewart_5|and is it just a thing satoshi did, or is there an actual attack that would be possible
 29 2017-01-08 03:28:12	0|gmaxwell|well it does simplify validation code when it doesn't have to check the count before accessing the first one... but no there isn't any special attack.
 30 2017-01-08 03:28:33	0|Chris_Stewart_5|gmaxwell: Thanks for the explanation :-)
 31 2017-01-08 03:35:22	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9488: Parallel ThreadMessageHandler (06master...062017-01-parallel-processmessages) 02https://github.com/bitcoin/bitcoin/pull/9488
 32 2017-01-08 03:41:31	0|gmaxwell|#7871 is sometihng I probably should have mentioned for a 0.14 target in the last meeting, it is highly complementary with importmulti.
 33 2017-01-08 03:41:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/7871 | Manual block file pruning. by mrbandrews · Pull Request #7871 · bitcoin/bitcoin · GitHub
 34 2017-01-08 03:44:12	0|gmaxwell|though the fact that one works based on time and the other based on height is a little awkward.
 35 2017-01-08 03:47:46	0|gmaxwell|oh weee. thats a bug.
 36 2017-01-08 04:19:23	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9489: Make FindLatestBefore use GetMedianTimePast instead of GetBlockTime. (06master...06fix_find_latest_before) 02https://github.com/bitcoin/bitcoin/pull/9489
 37 2017-01-08 04:25:53	0|luke-jr|Chris_Stewart_5: you *could* have a single output with zero value, note
 38 2017-01-08 04:39:59	0|Chris_Stewart_5|luke-jr: Or even negative value
 39 2017-01-08 04:40:03	0|Chris_Stewart_5|I think?
 40 2017-01-08 04:40:19	0|Chris_Stewart_5|BuildCreditingTransaction uses that inside of transaction_test.cpp any way...
 41 2017-01-08 04:45:42	0|sipa|wut?
 42 2017-01-08 04:46:58	0|sipa|negative value outputs?
 43 2017-01-08 04:54:41	0|bitcoin-git|[13bitcoin] 15gmaxwell closed pull request #9489: Make FindLatestBefore use GetMedianTimePast instead of GetBlockTime. (06master...06fix_find_latest_before) 02https://github.com/bitcoin/bitcoin/pull/9489
 44 2017-01-08 04:55:46	0|gmaxwell|sipa: will I be hated if I make the entries in CBlockIndex 8 bytes larger? :(
 45 2017-01-08 04:58:48	0|gmaxwell|I need a 'highest timestamp seen so far in this chain' for this FindLatestBefore.
 46 2017-01-08 05:00:38	0|gmaxwell|obvious way to do that is to just have a maxTime in the CBlockindex which = max(nTime,prev->maxtime). sorry 4 bytes, I guess our time there is only 32bits.
 47 2017-01-08 05:03:19	0|luke-jr|Chris_Stewart_5: I am relatively certain that negative value outputs are always invalid.
 48 2017-01-08 05:53:31	0|BlueMatt|gmaxwell: IIRC there are a good chunk more than 8 bytes available in CBlockIndex just from better packing
 49 2017-01-08 05:53:36	0|BlueMatt|so.....
 50 2017-01-08 05:58:49	0|kallewoof|I always thought bitcoin was supposed to pick the chain with the most work, not the longest chain. I did some testing, and with a split network bitcoin picked the longest chain, even though the shorter-by-one chain had a much lower hash.
 51 2017-01-08 05:59:47	0|kallewoof|I.e. (1) 5b6aab3f > 3d697a37 > 4ea2f338. (2) 5b6aab3f > 0000000b. On connecting nodes, result was (1) not (2).
 52 2017-01-08 06:03:09	0|kadoban|kallewoof: Wouldn't the difficulty at that point matter, not the actual hashes generated? Or did I make that up?
 53 2017-01-08 06:03:37	0|kallewoof|You mean nBits?
 54 2017-01-08 06:04:30	0|gmaxwell|kadoban: correct.
 55 2017-01-08 06:04:41	0|kadoban|I don't know the block format amazingly well, I only remember some parts at a conceptual level. nBits sounds possibly right though
 56 2017-01-08 06:04:49	0|kadoban|Ah good
 57 2017-01-08 06:04:54	0|gmaxwell|kadoban: other than sufficiency, the hash value doesn't have anything to do with the work that went into it.
 58 2017-01-08 06:05:25	0|gmaxwell|though nbits doesn't tell you the total work, it tells you how much work was required for a particular block.
 59 2017-01-08 06:06:03	0|gmaxwell|the total work is represented as nChainWork in the bitcoin codebase, it isn't seralized as part of the block.
 60 2017-01-08 06:06:13	0|kallewoof|So what is the point with the whole 'most work not longest chain' talk? Nbits is network-widely defined so there will not be a difference ever, will there?
 61 2017-01-08 06:06:32	0|gmaxwell|kallewoof: difficulty changes over time.
 62 2017-01-08 06:06:41	0|kallewoof|I mean, it's retargeted, but that's it
 63 2017-01-08 06:06:53	0|kallewoof|One client will not have one nbits value while another has a different one, hardly ever.
 64 2017-01-08 06:07:14	0|gmaxwell|...
 65 2017-01-08 06:07:25	0|gmaxwell|nbits is a property of the _chain_ not the client.
 66 2017-01-08 06:08:45	0|kallewoof|I mean... the work done to a chain is dependent on the accumulated difficulties (which are the nbits values, right?). I just can't think of a case where you would have a shorter chain being chosen due to more work.
 67 2017-01-08 06:09:59	0|gmaxwell|kallewoof: I can trivially go fork at block 100,000 and then hand you a chain with way more blocks then the current chain but massively less work.
 68 2017-01-08 06:10:30	0|gmaxwell|it's a trivial attack, and utterly devistating to most-blocks.
 69 2017-01-08 06:11:06	0|kallewoof|Ahh.. so that's what the whole 'most work' thing is about. I get it. Thanks.
 70 2017-01-08 06:11:25	0|gmaxwell|absent attacks, whenever there is a chain fork around a retarget, the two sides can have different amounts of work; which makes a difference though not a terribly critical one.
 71 2017-01-08 06:11:33	0|gmaxwell|no problem.
 72 2017-01-08 06:11:56	0|gmaxwell|kallewoof: lots of people miss that one, the bitcoin software was originally most blocks.
 73 2017-01-08 06:12:35	0|kallewoof|It is super obvious now that you've described it. I wish someone had worded it that way somewhere.
 74 2017-01-08 06:13:03	0|gmaxwell|it's the sort of thing that would have been described in the whitepaper, if it were known at the time. :)
 75 2017-01-08 06:14:19	0|gmaxwell|also, consider yourself fortunate: the worst position to be in is having never been surprised by anything; from that vantage you can't tell how subtle this stuff is... because it's all obvious when presented clearly.
 76 2017-01-08 06:17:45	0|kallewoof|gmaxwell: True enough. :)
 77 2017-01-08 06:21:19	0|kallewoof|Here's the log of my fine-but-failed experiment in case anyone wants to see it, btw: https://gist.github.com/kallewoof/9b0e541366941e08e41ab1bf3e03f017
 78 2017-01-08 07:23:44	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9490: Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. (06master...06fix_find_latest_before) 02https://github.com/bitcoin/bitcoin/pull/9490
 79 2017-01-08 08:39:09	0|gmaxwell|wump: I think #9404 could be merged.
 80 2017-01-08 08:39:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
 81 2017-01-08 08:57:05	0|gmaxwell|BlueMatt: I with the currently list of network messages in your parallel message handler list-- whats the point?  I also don't see how you can handle a GETBLOCKTXN without cs_main.  Do you intend on making it peek at the message further to decide if it will be able to use the cache?
 82 2017-01-08 11:35:11	0|fanquake|paveljanik what do you mean by diff-only related changes in 9469? The changes are required to make the patches apply cleanly..
 83 2017-01-08 11:35:54	0|paveljanik|fanquake, and this was my question :-) So they are to make the diff apply cleanly. OK. Np with that.
 84 2017-01-08 11:36:12	0|paveljanik|So we somewhere require the patch to apply cleanly?
 85 2017-01-08 11:38:23	0|fanquake|The patches are applied before building the dependancies, https://github.com/bitcoin/bitcoin/blob/master/depends/packages/libevent.mk#L8. There isn't a hard requirement that they apply perfectly, but it seems logical to update them to do so.
 86 2017-01-08 11:39:25	0|paveljanik|I do not think so ;-)
 87 2017-01-08 11:39:47	0|paveljanik|fanquake, ad config.* files - github shows then without final newlines at the end of them...
 88 2017-01-08 11:40:56	0|fanquake|paveljanik if you look at the source of them, http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess, I can't see any new lines. Maybe I'm missing something?
 89 2017-01-08 11:43:58	0|paveljanik|wget -O config.sub 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD' && hexdump -C config.sub | tail -2
 90 2017-01-08 11:44:06	0|paveljanik|shows 0x0a at the end.
 91 2017-01-08 11:45:47	0|paveljanik|the same for the other file.
 92 2017-01-08 11:47:03	0|fanquake|heh I can change it back, will investigate the OS X issue.
 93 2017-01-08 11:47:58	0|fanquake|paveljanik It'd be good if you could also review the contents/changelogs of the dependancy updates/hashes of said updates also.
 94 2017-01-08 11:48:16	0|paveljanik|I'm in the middle of it ;-)
 95 2017-01-08 11:49:11	0|fanquake|Newlines will be the least of our worries if we've got a borked boost version etc
 96 2017-01-08 11:50:50	0|paveljanik|Hmm, but we should not change the upstream files...
 97 2017-01-08 11:51:03	0|paveljanik|and these two are upstream files.
 98 2017-01-08 11:51:41	0|fanquake|paveljanik which files?
 99 2017-01-08 11:51:49	0|paveljanik|config.sub and config.guess
100 2017-01-08 11:52:19	0|fanquake|Why would we not update those?
101 2017-01-08 11:52:33	0|paveljanik|we should fetch them and store as-is in the depends, not modify them after fetching.
102 2017-01-08 11:52:36	0|paveljanik|update: yes!
103 2017-01-08 11:52:40	0|paveljanik|modify: no!
104 2017-01-08 11:52:50	0|paveljanik|You updated (good!) and modified (wrong!).
105 2017-01-08 11:53:07	0|paveljanik|but maybe the modification was not intentional...
106 2017-01-08 11:53:12	0|paveljanik|some tooling or so...
107 2017-01-08 11:53:16	0|fanquake|We're not patching/modifying them though?
108 2017-01-08 11:53:34	0|fanquake|oh your talking about the newlines? Yes that can be fixed.
109 2017-01-08 11:53:37	0|paveljanik|You did modify the file by deleting the final newline!
110 2017-01-08 11:53:40	0|paveljanik|yes
111 2017-01-08 11:53:57	0|paveljanik|BTW - why don't we fetch them too?
112 2017-01-08 11:55:02	0|fanquake|Probably something you'd have to ask theuni.
113 2017-01-08 11:55:47	0|fanquake|gmaxwell I think I must be missing something in #9484. Started a -reindex-chainstate with -assumevalid=<default hash>, and it's working far slower than just current master.
114 2017-01-08 11:55:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
115 2017-01-08 16:12:28	0|BlueMatt|gmaxwell: I mean it could only respond to getblocktxn if its the top-block (ie cached one)...I'm perfectly ok with it having a chance at blocking if it happens to be a request for the wrong block
116 2017-01-08 16:12:47	0|BlueMatt|gmaxwell: in the common case it'll work super well, in the rare case (or if your peer is mean) it might block
117 2017-01-08 16:12:59	0|BlueMatt|gmaxwell: in the future we could look deeper at the message to see if we will block
118 2017-01-08 16:13:10	0|sipa|gmaxwell: what does 'timestamp seen in a chain' mean?
119 2017-01-08 16:15:06	0|BlueMatt|gmaxwell: for 0.15 I may try to push a read/upgrade/write lock model again, which would also make this useful
120 2017-01-08 16:19:57	0|BlueMatt|gmaxwell: with real State() fixes, we could also support FILTERLOAD/FILTERADD/FILTERCLEAR/VERACK/ADDR/SENDHEADERS/
121 2017-01-08 16:20:44	0|BlueMatt|which, btw, is all of our non-block/tx-download non-version messages
122 2017-01-08 16:20:50	0|BlueMatt|and I think we could get version too
123 2017-01-08 16:20:59	0|BlueMatt|but it would take a tiny bit more work
124 2017-01-08 16:25:04	0|BlueMatt|maybe for 15 we could even get the mempool-can-be-behind-chainActive stuff like we have for wallet now
125 2017-01-08 16:25:19	0|BlueMatt|which would make this really awesome
126 2017-01-08 17:52:44	0|BlueMatt|sipa: you were asking about easy merges? #9480, #9353
127 2017-01-08 17:52:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
128 2017-01-08 17:52:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/9353 | Add data() method to CDataStream (and use it) by laanwj · Pull Request #9353 · bitcoin/bitcoin · GitHub
129 2017-01-08 18:29:24	0|BlueMatt|sipa: oh, and the one I actually meant to refer to : #9404
130 2017-01-08 18:29:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
131 2017-01-08 19:59:00	0|jm111t|just wanted to mention that about 2 months ago I reported  that I could not import a key and then by rebuilding the blockchain it worked again.
132 2017-01-08 19:59:14	0|jm111t|well I had the problem again and found out why. The reason is the file system, the problem arises when your drive is formated with msdos.
133 2017-01-08 19:59:45	0|jm111t|just in case it might help someone.
134 2017-01-08 20:08:30	0|luke-jr|BlueMatt: I don't think I can fix most of your nits without amending past commits..
135 2017-01-08 20:10:20	0|BlueMatt|luke-jr: thats fine...up to you to do that if its required (and no one has published partial reviews)...alternatively you could just add SQUASHME commits on top
136 2017-01-08 20:14:08	0|gmaxwell|sipa: I'm not sure of the context of your question, but I presume nTime.
137 2017-01-08 20:14:21	0|luke-jr|BlueMatt: that doesn't work for moving changes from commit X to X-1
138 2017-01-08 20:14:36	0|BlueMatt|ehh, i dont care if you fix that one
139 2017-01-08 20:14:51	0|BlueMatt|but if you get around to doing another rebase, might as well do it then
140 2017-01-08 20:20:11	0|luke-jr|BlueMatt: any suggestions for removing the pointer from the debug log? there's kinda nothing else unique..
141 2017-01-08 20:20:49	0|luke-jr|maybe it'd be okay with lockwallet(0x%x) instead of a decimal number?
142 2017-01-08 20:21:05	0|BlueMatt|yea, I dont have any great insight into that one...what do you use for wallet ids in the final multiwallet pr?
143 2017-01-08 20:21:30	0|BlueMatt|no, the point is to not print a pointer into debug.log, since I could contort it into an issue for ASLR
144 2017-01-08 20:24:23	0|luke-jr|BlueMatt: final multiwallet gives the wallets names, but there is no strong guarantee they won't have the same name
145 2017-01-08 20:25:59	0|luke-jr|I suppose I could use the filename if I move some parts of that into this
146 2017-01-08 20:26:01	0|BlueMatt|huh? if they have the same name how would you index them? dont you check name-uniqueness on load?
147 2017-01-08 20:26:26	0|luke-jr|they aren't indexed.
148 2017-01-08 20:26:34	0|BlueMatt|i mean for this pr you could just have a second id field in the scheduler thinggy that gets appended to the string after print
149 2017-01-08 20:26:42	0|BlueMatt|how do you specify the wallet?
150 2017-01-08 20:27:00	0|luke-jr|there's a dropdown box in the GUI, and for RPC by filename
151 2017-01-08 20:27:19	0|BlueMatt|oh, hum....
152 2017-01-08 20:27:43	0|luke-jr|hm, I suppose strWalletFile is already there
153 2017-01-08 20:27:55	0|luke-jr|and I guess we don't support files outside of .bitcoin or in subdirs
154 2017-01-08 20:28:21	0|BlueMatt|yea, I'd be more comfortable with just using that
155 2017-01-08 20:28:31	0|luke-jr|it's not a strong guarantee, but maybe good enough
156 2017-01-08 20:28:49	0|BlueMatt|well you certainly cant load two wallets with the same name???
157 2017-01-08 20:29:09	0|BlueMatt|oh, wait, no, you also cant load two wallets in the same dir, can you?
158 2017-01-08 20:29:13	0|BlueMatt|does bdb barf on that?
159 2017-01-08 20:29:42	0|luke-jr|you can only load two wallets in the same dir
160 2017-01-08 20:30:01	0|BlueMatt|oh? i guess its all the same bdb context thinggy?
161 2017-01-08 20:30:41	0|luke-jr|yes
162 2017-01-08 20:30:54	0|luke-jr|we don't actually enforce same-dir, but it's going to use the same bdb database dir I think
163 2017-01-08 20:32:21	0|BlueMatt|yes, probably
164 2017-01-08 20:32:28	0|BlueMatt|when in doubt, enforce, I'd say here
165 2017-01-08 20:32:34	0|BlueMatt|given bdb.........
166 2017-01-08 20:36:23	0|luke-jr|not really sure what to do with 989e352f7931f6ab9212e821e2d00e4aa0106635. Someone wanted it. :/
167 2017-01-08 20:37:31	0|BlueMatt|i mean the ones inside ifdef ENABLE_WALLET could be moved, and then you could #include inside an ENABLE_WALLET
168 2017-01-08 20:37:49	0|BlueMatt|but the include should only be inside an ENABLE_WALLET
169 2017-01-08 21:19:02	0|luke-jr|BlueMatt: okay, I think I got everything
170 2017-01-08 21:23:37	0|luke-jr|oh fun, master doesn't build :x
171 2017-01-08 21:24:07	0|BlueMatt|huh?
172 2017-01-08 21:24:13	0|BlueMatt|under what settings?
173 2017-01-08 21:25:18	0|luke-jr|test/raii_event_tests.cpp:39:58: error: ‘event_set_mem_functions’ was not declared in this scope
174 2017-01-08 21:26:36	0|gmaxwell|fanquake: doesn't bode well for reviewing the constants; when I updated for opening the pull request, I updated the constants, and managed to put a testnet block in the mainnet default. :)
175 2017-01-08 21:26:52	0|gmaxwell|fengling: it's fixed now.