1 2016-03-16T00:04:38  *** molz has joined #bitcoin-core-dev
  2 2016-03-16T00:07:46  *** moli has quit IRC
  3 2016-03-16T00:10:50  *** mrkent has joined #bitcoin-core-dev
  4 2016-03-16T00:29:12  *** Don_John has joined #bitcoin-core-dev
  5 2016-03-16T00:33:56  *** Don_John_ has joined #bitcoin-core-dev
  6 2016-03-16T00:35:53  *** Don_John_ has quit IRC
  7 2016-03-16T00:36:03  *** Don_John has quit IRC
  8 2016-03-16T00:48:45  *** dogu has joined #bitcoin-core-dev
  9 2016-03-16T00:56:01  *** dogu has quit IRC
 10 2016-03-16T00:56:05  *** BashCo_ has joined #bitcoin-core-dev
 11 2016-03-16T00:58:25  *** BashCo has quit IRC
 12 2016-03-16T01:17:03  *** fredrin has quit IRC
 13 2016-03-16T01:20:05  *** fredrin has joined #bitcoin-core-dev
 14 2016-03-16T01:24:51  *** fredrin has quit IRC
 15 2016-03-16T01:32:58  *** fredrin has joined #bitcoin-core-dev
 16 2016-03-16T01:40:59  *** Ylbam has quit IRC
 17 2016-03-16T01:41:54  *** jtimon has quit IRC
 18 2016-03-16T01:45:16  *** fengling has joined #bitcoin-core-dev
 19 2016-03-16T01:53:27  *** ghtdak has quit IRC
 20 2016-03-16T02:22:45  *** justanot1eruser has joined #bitcoin-core-dev
 21 2016-03-16T02:23:02  *** justanotheruser has quit IRC
 22 2016-03-16T02:36:25  *** ghtdak has joined #bitcoin-core-dev
 23 2016-03-16T02:40:54  <GitHub1> [bitcoin] EthanHeilman opened pull request #7696: Fix de-serialization bug where AddrMan is left corrupted (master...bug) https://github.com/bitcoin/bitcoin/pull/7696
 24 2016-03-16T02:42:53  *** achow101 has quit IRC
 25 2016-03-16T02:45:56  *** fengling has quit IRC
 26 2016-03-16T02:46:52  *** fengling has joined #bitcoin-core-dev
 27 2016-03-16T02:49:53  *** achow101 has joined #bitcoin-core-dev
 28 2016-03-16T02:51:03  *** Chris_Stewart_5 has quit IRC
 29 2016-03-16T02:51:16  <achow101> will there be a full write up of the details of the segwit changes so that wallet developers can work on its implementation?
 30 2016-03-16T02:51:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 31 2016-03-16T02:51:33  <achow101> preferably before the release of the client with segwit?
 32 2016-03-16T03:08:41  *** mrkent has quit IRC
 33 2016-03-16T03:09:59  *** Bob777 has joined #bitcoin-core-dev
 34 2016-03-16T03:11:33  *** AaronvanW has quit IRC
 35 2016-03-16T03:23:55  *** AaronvanW has joined #bitcoin-core-dev
 36 2016-03-16T03:27:51  *** wallet42 has joined #bitcoin-core-dev
 37 2016-03-16T03:41:51  *** aknix has quit IRC
 38 2016-03-16T03:49:39  *** evoskuil has quit IRC
 39 2016-03-16T03:50:01  *** evoskuil has joined #bitcoin-core-dev
 40 2016-03-16T03:53:30  *** achow101 has quit IRC
 41 2016-03-16T03:59:02  *** Alopex has quit IRC
 42 2016-03-16T04:00:07  *** Alopex has joined #bitcoin-core-dev
 43 2016-03-16T04:03:43  *** pavel_ has joined #bitcoin-core-dev
 44 2016-03-16T04:06:15  *** paveljanik has quit IRC
 45 2016-03-16T04:06:21  *** Giszmo has quit IRC
 46 2016-03-16T04:14:14  *** Bob777 has quit IRC
 47 2016-03-16T04:35:14  *** shesek has quit IRC
 48 2016-03-16T04:36:58  *** shesek has joined #bitcoin-core-dev
 49 2016-03-16T04:42:01  *** Alopex has quit IRC
 50 2016-03-16T04:43:06  *** Alopex has joined #bitcoin-core-dev
 51 2016-03-16T04:52:25  *** Thireus has quit IRC
 52 2016-03-16T05:06:01  *** Alopex has quit IRC
 53 2016-03-16T05:07:06  *** Alopex has joined #bitcoin-core-dev
 54 2016-03-16T05:36:01  *** Alopex has quit IRC
 55 2016-03-16T05:37:07  *** Alopex has joined #bitcoin-core-dev
 56 2016-03-16T05:38:43  *** zooko has joined #bitcoin-core-dev
 57 2016-03-16T06:01:18  *** pavel_ has quit IRC
 58 2016-03-16T06:01:27  *** paveljanik has joined #bitcoin-core-dev
 59 2016-03-16T06:01:27  *** paveljanik has joined #bitcoin-core-dev
 60 2016-03-16T06:05:52  *** Chris_Stewart_5 has quit IRC
 61 2016-03-16T06:10:33  *** zooko has quit IRC
 62 2016-03-16T06:12:02  *** Alopex has quit IRC
 63 2016-03-16T06:12:25  *** Thireus has joined #bitcoin-core-dev
 64 2016-03-16T06:13:07  *** Alopex has joined #bitcoin-core-dev
 65 2016-03-16T06:27:09  *** BashCo has joined #bitcoin-core-dev
 66 2016-03-16T06:29:23  *** BashCo_ has quit IRC
 67 2016-03-16T07:40:27  *** gribble has quit IRC
 68 2016-03-16T07:44:00  *** Ylbam has joined #bitcoin-core-dev
 69 2016-03-16T07:47:10  *** PRab has quit IRC
 70 2016-03-16T07:50:23  *** gribble has joined #bitcoin-core-dev
 71 2016-03-16T07:50:41  *** Thireus has quit IRC
 72 2016-03-16T08:00:36  *** JackH has joined #bitcoin-core-dev
 73 2016-03-16T08:09:32  *** BashCo has quit IRC
 74 2016-03-16T08:10:07  *** BashCo has joined #bitcoin-core-dev
 75 2016-03-16T08:11:52  *** Thireus has joined #bitcoin-core-dev
 76 2016-03-16T08:14:52  *** BashCo has quit IRC
 77 2016-03-16T08:16:47  *** slackircbridge has quit IRC
 78 2016-03-16T08:17:21  *** slackircbridge has joined #bitcoin-core-dev
 79 2016-03-16T08:21:22  *** cjcj has quit IRC
 80 2016-03-16T08:22:19  *** Guyver2 has joined #bitcoin-core-dev
 81 2016-03-16T08:27:27  *** AaronvanW has quit IRC
 82 2016-03-16T08:30:19  *** BashCo has joined #bitcoin-core-dev
 83 2016-03-16T08:36:05  *** cjcj has joined #bitcoin-core-dev
 84 2016-03-16T08:36:09  *** Tasoshi has quit IRC
 85 2016-03-16T08:40:15  *** AaronvanW has joined #bitcoin-core-dev
 86 2016-03-16T09:31:46  *** cjcj has quit IRC
 87 2016-03-16T10:02:02  *** randy-waterhouse has quit IRC
 88 2016-03-16T10:21:45  *** laurentmt has joined #bitcoin-core-dev
 89 2016-03-16T10:23:37  *** laurentmt has quit IRC
 90 2016-03-16T10:39:23  *** AaronvanW has quit IRC
 91 2016-03-16T10:40:56  *** Guyver2 has quit IRC
 92 2016-03-16T10:48:46  *** AaronvanW has joined #bitcoin-core-dev
 93 2016-03-16T10:48:47  *** AaronvanW has quit IRC
 94 2016-03-16T10:48:47  *** AaronvanW has joined #bitcoin-core-dev
 95 2016-03-16T11:26:47  *** Guyver2 has joined #bitcoin-core-dev
 96 2016-03-16T11:28:49  *** jtimon has joined #bitcoin-core-dev
 97 2016-03-16T11:38:28  *** murch has joined #bitcoin-core-dev
 98 2016-03-16T12:51:48  *** hsmiths2 has quit IRC
 99 2016-03-16T12:52:17  *** hsmiths has joined #bitcoin-core-dev
100 2016-03-16T13:15:56  *** B4ckJ4ck007 has joined #bitcoin-core-dev
101 2016-03-16T13:22:26  *** B4ckJ4ck007 has left #bitcoin-core-dev
102 2016-03-16T13:23:31  *** B4ckJ4ck007 has joined #bitcoin-core-dev
103 2016-03-16T13:23:43  *** B4ckJ4ck007 has left #bitcoin-core-dev
104 2016-03-16T13:24:29  *** B4ckJ4ck007 has joined #bitcoin-core-dev
105 2016-03-16T13:26:14  *** B4ckJ4ck007 has quit IRC
106 2016-03-16T13:26:37  *** B4ckJ4ck007 has joined #bitcoin-core-dev
107 2016-03-16T13:44:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
108 2016-03-16T13:56:23  *** laurentmt has joined #bitcoin-core-dev
109 2016-03-16T13:56:57  *** laurentmt has quit IRC
110 2016-03-16T14:27:26  <GitHub25> [bitcoin] sdaftuar opened pull request #7697: Tests: make prioritise_transaction.py more robust (master...fix-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/7697
111 2016-03-16T14:28:04  *** zooko has joined #bitcoin-core-dev
112 2016-03-16T14:43:00  *** Guyver2_ has joined #bitcoin-core-dev
113 2016-03-16T14:45:32  *** Guyver2 has quit IRC
114 2016-03-16T14:45:34  *** Guyver2_ is now known as Guyver2
115 2016-03-16T14:53:42  *** xiangfu has quit IRC
116 2016-03-16T14:59:26  *** xiangfu has joined #bitcoin-core-dev
117 2016-03-16T15:06:09  <Chris_Stewart_5> Hi guys, I know this isn't the correct channel, but I figured some one in this channel might be able to answer my question - i've already tried #bitcoin-dev
118 2016-03-16T15:06:28  <Chris_Stewart_5> I'm looking at this test case from script_valid.json that is suppose to pass in core
119 2016-03-16T15:06:30  <Chris_Stewart_5> ["0x4a 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "0 CHECKSIG NOT", "", "Overly long signature is correctly encoded"]
120 2016-03-16T15:06:53  <Chris_Stewart_5> however the signature 0x00...000 isn't a valid DER signature - so why is this test case suppose to pass?
121 2016-03-16T15:08:13  <Chris_Stewart_5> interestingly enough, that same test case is also included in script_invalid.json as well
122 2016-03-16T15:09:15  <sipa> that test doesn't specify DERSIG as validation flag
123 2016-03-16T15:09:43  <Chris_Stewart_5> sipa: So this is a historical test case pre BIP-66?
124 2016-03-16T15:09:44  <sipa> or STRICTENC or LOW_S
125 2016-03-16T15:09:45  <wumpus> intersting
126 2016-03-16T15:09:56  <wumpus> I think he got confused by ["Increase test coverage for DERSIG"]
127 2016-03-16T15:10:02  <sipa> Chris_Stewart_5: in a way...
128 2016-03-16T15:10:11  <wumpus> after which none of the test cases supply the DERSIG flag :-)
129 2016-03-16T15:10:12  <sipa> Chris_Stewart_5: the consensus rules are still well defined for historical cases
130 2016-03-16T15:10:38  <wumpus> (some do, later on, but not under that heading)
131 2016-03-16T15:10:54  <sipa> wumpus: compare that section to the corresponding section in script_invalid; the tests verify the difference in validity by setting/unsetting that flag
132 2016-03-16T15:11:16  <wumpus> sipa: I believe you that it's correct, it just looks funny
133 2016-03-16T15:11:24  <sipa> that's the typical way these tests are constructed: find the minimal set of flag difference that cause validity to change, and put one side in valid and one side in invalid
134 2016-03-16T15:11:32  <sipa> probably deserves a comment!
135 2016-03-16T15:11:37  <wumpus> right
136 2016-03-16T15:15:33  <Chris_Stewart_5> thanks guys, If I am understanding this correctly, we would have to deploy another soft fork to make this signature valid again for bitcoin core nodes? Are the flags in the test case used ONLY for these test cases or is there similar flags used in bitcoin core's interpreter?
137 2016-03-16T15:15:33  *** davec has quit IRC
138 2016-03-16T15:15:59  *** davec has joined #bitcoin-core-dev
139 2016-03-16T15:16:11  <sipa> Chris_Stewart_5: it would require a hard fork to make them valid again
140 2016-03-16T15:16:45  <sipa> Chris_Stewart_5: that specific test tests the script evaluation engine, which does not know anything about consensus rules or transactions or blocks even
141 2016-03-16T15:16:57  <sipa> so it specifies the flags for evaluation with each test
142 2016-03-16T15:17:24  <sipa> other, higher-level tests exist that actually check whether the consensus logic evaluates things correctly
143 2016-03-16T15:17:42  <Chris_Stewart_5> sipa: Is that right though? Obviously OP_CHECKSIG has to know about txs because they are needed for hashing to compare against the sigs?
144 2016-03-16T15:17:58  <Chris_Stewart_5> or OP_CHECKMULTISIG
145 2016-03-16T15:18:28  <sipa> Chris_Stewart_5: nope, it's abstracted through BaseSignatureChecker
146 2016-03-16T15:18:53  <sipa> and then there is an implementation for that for CTransaction, but it can be used to verify signatures on other things than transactions
147 2016-03-16T15:19:06  <Chris_Stewart_5> interesting, I"ve been trying to model something similar in Scala, i'll have to take a closer look
148 2016-03-16T15:19:37  <Chris_Stewart_5> I think i was just running into this problem of who knows about what (does the interpreter needs to know about txs etc..)
149 2016-03-16T15:20:26  <sipa> there were some plans of introducing a new message signing feature based on this, so that you can do multisigs on a message, for example
150 2016-03-16T15:23:12  *** Giszmo has joined #bitcoin-core-dev
151 2016-03-16T15:27:57  *** MarcoFalke has joined #bitcoin-core-dev
152 2016-03-16T15:31:21  *** zooko has quit IRC
153 2016-03-16T16:00:39  *** MarcoFalke has quit IRC
154 2016-03-16T16:14:01  *** B4ckJ4ck007 has quit IRC
155 2016-03-16T16:19:20  *** jtimon has quit IRC
156 2016-03-16T16:23:27  *** BashCo has quit IRC
157 2016-03-16T16:24:04  *** BashCo has joined #bitcoin-core-dev
158 2016-03-16T16:25:59  *** jtimon has joined #bitcoin-core-dev
159 2016-03-16T16:29:06  *** BashCo has quit IRC
160 2016-03-16T16:32:29  <GitHub191> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/a6a860796a44...3d0dfdbf9f26
161 2016-03-16T16:32:30  <GitHub191> bitcoin/master fa3a81a MarcoFalke: [tests] Extend util_ParseMoney test case
162 2016-03-16T16:32:30  <GitHub191> bitcoin/master fad7dc8 MarcoFalke: [qa] wallet: speed up tests
163 2016-03-16T16:32:31  <GitHub191> bitcoin/master fa8cd46 MarcoFalke: [qa] Move create_tx() to util.py
164 2016-03-16T16:32:39  <GitHub140> [bitcoin] laanwj closed pull request #7684: [qa] Extend tests (master...Mf1603-qaCleanup1) https://github.com/bitcoin/bitcoin/pull/7684
165 2016-03-16T16:48:23  *** BashCo has joined #bitcoin-core-dev
166 2016-03-16T17:07:14  *** laurentmt has joined #bitcoin-core-dev
167 2016-03-16T17:13:14  *** Thireus has quit IRC
168 2016-03-16T17:20:25  *** Chris_Stewart_5 has quit IRC
169 2016-03-16T17:22:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
170 2016-03-16T17:34:43  *** Thireus has joined #bitcoin-core-dev
171 2016-03-16T17:38:45  *** mrkent has joined #bitcoin-core-dev
172 2016-03-16T17:46:08  <btcdrak> has anyone complained to Github about the sort order of commits on PRs?
173 2016-03-16T17:47:36  <sipa> btcdrak: they're sorted by date
174 2016-03-16T17:47:39  <sipa> https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/
175 2016-03-16T17:59:13  *** MarcoFalke has joined #bitcoin-core-dev
176 2016-03-16T18:02:30  <MarcoFalke> wumpus around?
177 2016-03-16T18:06:45  *** molz has quit IRC
178 2016-03-16T18:07:07  *** molz has joined #bitcoin-core-dev
179 2016-03-16T18:13:55  *** wallet421 has joined #bitcoin-core-dev
180 2016-03-16T18:14:30  <btcdrak> hunt the wumpus https://www.youtube.com/watch?v=xGVOw8gXl6Y
181 2016-03-16T18:16:03  *** wallet42 has quit IRC
182 2016-03-16T18:24:12  <paveljanik> btcdrak, red ferrari started and wnt away. Ah, this was ad ;-))
183 2016-03-16T18:55:40  *** MarcoFalke has quit IRC
184 2016-03-16T18:56:28  *** murch has left #bitcoin-core-dev
185 2016-03-16T19:05:08  <GitHub116> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d0dfdbf9f26...622fe6c32f41
186 2016-03-16T19:05:08  <GitHub116> bitcoin/master ec14339 Suhas Daftuar: Tests: make prioritise_transaction.py more robust
187 2016-03-16T19:05:09  <GitHub116> bitcoin/master 622fe6c Wladimir J. van der Laan: Merge #7697: Tests: make prioritise_transaction.py more robust...
188 2016-03-16T19:05:17  <GitHub103> [bitcoin] laanwj closed pull request #7697: Tests: make prioritise_transaction.py more robust (master...fix-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/7697
189 2016-03-16T19:06:30  <CodeShark> btcdrak: the original text version in BASIC: https://youtu.be/9BsliGry-OA
190 2016-03-16T19:12:24  *** MarcoFalke has joined #bitcoin-core-dev
191 2016-03-16T19:21:05  <wumpus> MarcoFalke: yes (but not for long)
192 2016-03-16T19:21:15  <MarcoFalke> wumpus, I was wondering what you think about the patches toGetFee()
193 2016-03-16T19:21:38  <wumpus> haven't really looked at that yet
194 2016-03-16T19:21:52  <wumpus> most of the fee logic honestly confuses me
195 2016-03-16T19:22:09  <MarcoFalke> Jup the current logic even has a bug
196 2016-03-16T19:22:27  <MarcoFalke> GetFee() is not monotonic in the size
197 2016-03-16T19:22:37  <MarcoFalke> Would be trivial to fix
198 2016-03-16T19:22:43  <wumpus> I''m not surprised - I think we should first document what we want, then try to achieve that in the code
199 2016-03-16T19:23:15  <MarcoFalke> So I'd prefer to keep the integer logic (truncate)
200 2016-03-16T19:23:18  <wumpus> currently it's impossible to say if behavior is desirable or not
201 2016-03-16T19:23:27  <MarcoFalke> morcos and jtimon suggested to make it always ceil
202 2016-03-16T19:23:46  <wumpus> well at the very least please don't use doubles for monetary values
203 2016-03-16T19:24:09  <wumpus> I don't have an opinion on ceil versus floor, that'd at most make a satoshi difference I guess?
204 2016-03-16T19:24:19  <MarcoFalke> sure
205 2016-03-16T19:24:40  <MarcoFalke> but ceil at least needs a double for the time of calculation
206 2016-03-16T19:24:41  <wumpus> so go with whatever results in the simplest code
207 2016-03-16T19:25:14  <wumpus> you don't ever *need* doubles
208 2016-03-16T19:25:20  <jtimon> I think avoiding the optional param as suggested by morcos certainly simplifies things
209 2016-03-16T19:25:24  <morcos> MarcoFalke: Why do we NEED to change something?
210 2016-03-16T19:25:46  <MarcoFalke> we need at least make getFee() monotonic
211 2016-03-16T19:25:56  <morcos> ehh
212 2016-03-16T19:25:59  <wumpus> morcos: yes, that's what first needs to be decided
213 2016-03-16T19:26:17  *** mol11111 has joined #bitcoin-core-dev
214 2016-03-16T19:26:38  <morcos> MarcoFalke: btw, i'm totally fine with just truncating all the time too, but you were against truncating to 0
215 2016-03-16T19:26:45  <morcos> what i dont' want is more complexity
216 2016-03-16T19:26:49  <wumpus> if we don't need to change something that'd be preferable, so we can catch up to document the current behavior
217 2016-03-16T19:26:51  <jtimon> to be honest I'm still not sure what this is all about, even after reading the 2 PRs
218 2016-03-16T19:27:18  <MarcoFalke> ok, I will submit a minimal code change patch this evening
219 2016-03-16T19:27:22  <wumpus> if we could describe things in human understandable terms that'd help devs too
220 2016-03-16T19:27:29  *** mol11111 is now known as moli
221 2016-03-16T19:27:37  <wumpus> as said, I've been maintaining this code for years and the fee code freaks me out
222 2016-03-16T19:28:16  <jtimon> what about always truncating but instead of ever returning 0, just return 1 satoshi?
223 2016-03-16T19:28:19  <wumpus> at least if there's a large change in behavior we should document it in the release notes next time :)
224 2016-03-16T19:28:33  *** molz has quit IRC
225 2016-03-16T19:28:34  <MarcoFalke> jtimon, that's what I am going to do
226 2016-03-16T19:28:39  <morcos> wumpus: i know you say you don't like doubles, but the mining code and the fee estimation code which are the things that use fee rates, both use them as doubles
227 2016-03-16T19:28:41  <MarcoFalke> will result in least code and diff
228 2016-03-16T19:28:49  <wumpus> morcos: that's awful
229 2016-03-16T19:29:33  <jtimon> MarcoFalke: oh, nice, what's the problem with returning 0 in the first place anywa?
230 2016-03-16T19:30:07  <MarcoFalke> we still use it in the wallet to "detect" what the user selected
231 2016-03-16T19:30:22  <MarcoFalke> paytxfee or confirmtarget
232 2016-03-16T19:30:33  <jtimon> and now the user can't select 0 fee?
233 2016-03-16T19:30:35  <wumpus> doubles don't have exactly the same behavior on all platforms, which make it dangerous to use them for monetary values, we've had some strange reports of behavior while using doubles in the RPC layer
234 2016-03-16T19:30:51  <morcos> wumpus: i mean i said that kind of for effect, its not really awful the way its used, and i'm fine keeping CFeeRate to not use doubles, but its worth keeping in mind that we're losing precision by converting it to some weird integer
235 2016-03-16T19:30:53  <wumpus> now we've got rid of them there
236 2016-03-16T19:31:19  <jtimon> just use int satoshis everywhere
237 2016-03-16T19:31:34  <morcos> but its satoshis per size
238 2016-03-16T19:31:39  <wumpus> morcos: if you lose precision with integer arithmetic at least in a predictable, deterministic, platform independent way :)
239 2016-03-16T19:32:00  <wumpus> but it should be possible not to lost precision, if you use the right amount of fixed point precision
240 2016-03-16T19:32:15  <MarcoFalke> Using doubles for bitcoin should be fine right now, as a double can hold all possible values with exact precision IIRC.
241 2016-03-16T19:32:25  <MarcoFalke> But we should avoid it for consistency
242 2016-03-16T19:32:28  <morcos> wumpus: well for instance in the mining (actually mempool sorting) code its calculation using integers but they are converted to doubles to ignore overflow risk
243 2016-03-16T19:32:29  <wumpus> 'should be fine' but please don't
244 2016-03-16T19:33:02  <wumpus> they said the same about using doubles in RPC, and there's been some strange rounding errors
245 2016-03-16T19:33:03  <MarcoFalke> Jup, people will look at the code and think this is best practise
246 2016-03-16T19:33:15  <morcos> anywya, we're not talking about using doubles for an amount, i think everyone would 100% agree, that no bitcoin amount should ever be represented as a double  (bitcoins.satoshis)
247 2016-03-16T19:33:25  <jtimon> I guess CFeeRate's ```/ 1000``` simplifies some parts of the code, but I still dislike the whole concept (and much more that this code is included in current libconsensus)
248 2016-03-16T19:33:38  <sdaftuar> CFeeRate is in libconsensus?
249 2016-03-16T19:34:24  <MarcoFalke> jtimon, you mean IsDust()?
250 2016-03-16T19:34:43  <wumpus> I'd really prefer to stick to the point that doubles and floating point arithmetic dosn't belong in financial software
251 2016-03-16T19:34:57  <jtimon> yes, from the beginning, I've been trying to move it out ever since without luck, but if someone else wants to rewrite any of my attempts I'm more than happy to review
252 2016-03-16T19:36:22  <wumpus> I'm sure it is not used by any actual consensus code and could be moved out of libconsensus in due time
253 2016-03-16T19:36:58  <jtimon> MarcoFalke: IsDust and dustThereshold too, that's the reason why it cannot simply be moved out (amount.h would remain without .cpp or all its code can be simply moved back to primitives/transaction.h but then policy/feerate.o needs to depend on the whole consensus/transaction.o instead of only amount.h)
254 2016-03-16T19:37:21  <jtimon> wumpus: it can be moved out of consensus at any time
255 2016-03-16T19:37:27  <wumpus> jtimon: right
256 2016-03-16T19:38:09  <jtimon> for the first version that was small enough to just leave it for later, but we're leaving it for later ever since
257 2016-03-16T19:38:38  <jtimon> s/we're/we've been
258 2016-03-16T19:39:56  <wumpus> anyhow, re; fee, I think we should first have a plan what we really want, what is the current behavior, what is the intended behavior, before we just start changing code again and surpise users
259 2016-03-16T19:40:08  <morcos> wumpus: to summarize what i think the CFeeRate current problem is , we definited it as satoshis/kB which doesn't have enough precision as an integer to not be a bit annoying (both close to 0 and too many ties in mempool sorting).  not super annoying, but it was a bit of a silly definition
260 2016-03-16T19:41:46  <wumpus> morcos: yes I fully agree the current implementation of CFeeRate is somewhat silly
261 2016-03-16T19:42:06  <jtimon> I guess the advantage of using KB instead of just bytes it's to contemplate fees below 1 satoshi per byte, which I have no idea if currently makes sense
262 2016-03-16T19:42:44  <morcos> yes, jtimon from a human communication format satoshis/B makes more sense, but for precision, you really want satoshis/MB
263 2016-03-16T19:43:02  <jtimon> so any more generic replacement to contemplate lower fees would do it, I think
264 2016-03-16T19:43:14  <wumpus> well the internal representation doesn't have to depend on human communication format at all
265 2016-03-16T19:43:21  <wumpus> it cen be presented in whatever way makes sense to the user
266 2016-03-16T19:43:37  <morcos> well CFeeRate is almost only for human communication format
267 2016-03-16T19:43:52  <morcos> most things internally store fees and size separately
268 2016-03-16T19:43:57  <morcos> and do the calculations as necessary
269 2016-03-16T19:44:08  <jtimon> alright, so we need more precission and 1000 happens to be too small of a divider some times. what about an optional bytes param that defaults to 1000 ?
270 2016-03-16T19:44:12  <wumpus> human communication depends on the formatting function only
271 2016-03-16T19:44:13  <morcos> or like the estimation code use doubles b/c they're doing all kinds of crazy exponential decays and stuff
272 2016-03-16T19:44:58  <wumpus> jtimon: you mean make it a rational?
273 2016-03-16T19:45:26  <jtimon> I think that would open the door to some more simplifications for cases where you multiply by 1000 and divide by tx_size right after dividing by 1000 in the exnapsulated stuff
274 2016-03-16T19:45:30  <wumpus> well it's better than a double :)
275 2016-03-16T19:46:26  <jtimon> no, wait I've probably said something stupid, let me think more while looking at code
276 2016-03-16T19:46:59  <morcos> well, its not causing me any issues right now, so i prefer no changes to anything that isn't an obvious improvement
277 2016-03-16T19:47:08  <wumpus> morcos: absolutely
278 2016-03-16T19:47:24  <wumpus> that's my whole point about the fee logic, really
279 2016-03-16T19:49:31  <wumpus> first consider what is the current case, and what we want, so we can define what is an improvement
280 2016-03-16T19:50:36  <morcos> the problem MarcoFalke is trying to solve (or at least part of it) isnt' a problem with CFeeRate, but with a shortcut in how we detect whether the user has selected to paytxfee
281 2016-03-16T19:51:14  <morcos> it would make more sense to find out whether the paytxfee option has been set, and not whether it = 0 or rounds to 0 in terms of decidign whether to use dynamic fee estimation
282 2016-03-16T19:51:26  <morcos> thats would be the ideal fix, but that would be a change of behavior potentially for users
283 2016-03-16T19:51:51  <wumpus> I've been kind of caught by surprise by the fPayAtLeastCustomFee stuff, for example
284 2016-03-16T19:52:51  <morcos> right now you can't select paytxfee=0  , that just seems silly, you should be able to set whatever fee you want, and if you select a fee, you don't use fee estimation, even if your fee rounds/truncates/ceilings/doubles/or trampolines to 0
285 2016-03-16T19:53:01  <wumpus> https://github.com/bitcoin/bitcoin/issues/7633#issuecomment-195254622   I'd really like to avoid this another time
286 2016-03-16T19:53:45  <wumpus> "how we detect whether the user has selected to paytxfee" let's just follow the straightforward route and add a boolean then
287 2016-03-16T19:53:58  <wumpus> second guessing the user sucks
288 2016-03-16T19:55:24  <wumpus> sure - we can change the API, it's not prohobitive to change the behavior at all, just be sure to mention it in the release notes :)
289 2016-03-16T19:56:20  <MarcoFalke> I should have done the release notes as part of the pull probably. Still, no one yelled at me all the time before 0.12 was released. Even though my original pull was from September.
290 2016-03-16T19:56:30  <wumpus> and we shoudl really write a document what the various fee options do, how they interact, what is the result in practice
291 2016-03-16T19:56:45  <wumpus> it's soo flexible that no one understands really :)
292 2016-03-16T19:57:41  <wumpus> I'm not blaming you at all MarcoFalke, it's a strange coincidence of circumstances
293 2016-03-16T19:57:44  <MarcoFalke> you suggested to add a .md in /doc? I'd rather not do this taking considering that you need a pull every time someone wants to edit the file.
294 2016-03-16T19:57:55  <wumpus> I don't care where
295 2016-03-16T19:58:21  <MarcoFalke> bitcoin wiki it?
296 2016-03-16T19:58:26  <MarcoFalke> or the website?
297 2016-03-16T19:58:37  <MarcoFalke> Do we have infrastructure on the website for documentation yet?
298 2016-03-16T19:58:40  <wumpus> fine with me, I usually put stuff in gists but that's hard to find I suppose
299 2016-03-16T19:58:48  <wumpus> well on the website you need a pull for every change too
300 2016-03-16T19:59:34  <MarcoFalke> but bitcoin/bitcoin commits are read by somewhat more people than the website commits
301 2016-03-16T19:59:42  <wumpus> wikis have the problem that there's no change control at all
302 2016-03-16T19:59:49  <wumpus> that's why we moved the BIPs to git
303 2016-03-16T20:00:36  <wumpus> anyhow this isn't imporant, if you write it you get to decide where to put it
304 2016-03-16T20:02:36  <wumpus> bitcoin.org has extensive infrastructure for documentation, don't think bitcoincore.org has
305 2016-03-16T20:03:31  <morcos> what do you think about changing the names of those options.  i mean i know thats annoying.  but calling them paytxfeerate instead of paytxfee would make a whole lot more sense
306 2016-03-16T20:04:16  <morcos> i don't know if its easy enough to do that in a compatible way, i guess we'd have to consolidate where the arguments are looked at
307 2016-03-16T20:04:39  <wumpus> why not just document them better instead of change the name :)
308 2016-03-16T20:05:14  <morcos> yeah i guess there are a ton of them
309 2016-03-16T20:05:52  <wumpus> I mean for a clean slate, in retrospect, it would be awesome to name them differently, and as in any program there are plenty of awkwarly named options... but yes there's a strong backward compatibiltiy versus sensibility for new users compromise
310 2016-03-16T20:06:06  <GitHub37> [bitcoin] MarcoFalke closed pull request #7660: [amount] Extend GetFee() by optional flag ceil (master...Mf1603-amountCeil) https://github.com/bitcoin/bitcoin/pull/7660
311 2016-03-16T20:06:16  <GitHub110> [bitcoin] MarcoFalke closed pull request #7661:  [wallet] Round up to the next satoshi on odd fee rates  (master...Mf1603-walletCeil) https://github.com/bitcoin/bitcoin/pull/7661
312 2016-03-16T20:07:11  <wumpus> and it's possible to argue that the name of the options themselves is just arbitrary, it's just a name, as long as it's not completely deceptive what matters is how they're documented
313 2016-03-16T20:07:46  <MarcoFalke> Would be great to have different option names map to the same option to be used as synonyms... Which brings us back to the rewrite of the arg parser...
314 2016-03-16T20:08:14  <wumpus> well we do have some options that just throw an error if you provide them, and mention that they're either removed or have a new name
315 2016-03-16T20:08:42  <wumpus> but there's got to be a good motivation to do that, it shouldn't look like just sending the user on a wild goose chase :)
316 2016-03-16T20:08:48  <MarcoFalke> paytxfee is still widely used. Would be nasty to require everyone change their conf
317 2016-03-16T20:09:09  <morcos> wumpus: btw, i made your change to 7187, should i go ahead and squash all the commits, not sure if you thought review was done
318 2016-03-16T20:09:34  <MarcoFalke> wumpus any update on "wumpus: Would it be possible for us to arrange open source licenses of the Jetbrains IDEs for C++ and Python? They offer free licenses to projects like this"
319 2016-03-16T20:09:50  <wumpus> e.g. there's an issue to rename '-rescan' becuase many people use it out of confusion... well, yes, but you can't really keep the new name secret to clueless users :)
320 2016-03-16T20:10:21  <wumpus> morcos: I think review was good for that, we should merge it
321 2016-03-16T20:10:40  <wumpus> MarcoFalke: yea will do that, haven't got around to it
322 2016-03-16T20:10:56  <wumpus> morcos: (and squash, yes)
323 2016-03-16T20:13:14  <MarcoFalke> morcos (and others) Make sure to have the commit id somewhere in the GitHub discussion before you squash. Otherwise it's less transparent and harder to re-review if the reviewer hasn't pulled your repo yet.
324 2016-03-16T20:13:25  <wumpus> morcos: I think changing the semantics in potentially dangerous way would be a good reason to rename them, and error when the old name is used
325 2016-03-16T20:13:49  <morcos> wumpus: like maxsigcachesize  :)
326 2016-03-16T20:16:34  <morcos> ok done
327 2016-03-16T20:16:37  <wumpus> morcos: ehh that changed from entries to MiB didn't it
328 2016-03-16T20:16:57  <wumpus> morcos: yes, luckily it's an option no one knows about :)
329 2016-03-16T20:17:01  <morcos> yeah, i mean the damage is probably not that large, just an unlimited sigcache
330 2016-03-16T20:17:24  <wumpus> but yes it'd have made sense to change the name
331 2016-03-16T20:19:30  *** MarcoFalke has quit IRC
332 2016-03-16T20:20:28  <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/622fe6c32f41...14d6324a248d
333 2016-03-16T20:20:28  <GitHub33> bitcoin/master 982670c Alex Morcos: Add LockPoints...
334 2016-03-16T20:20:29  <GitHub33> bitcoin/master 14d6324 Wladimir J. van der Laan: Merge #7187: Keep reorgs fast for SequenceLocks checks...
335 2016-03-16T20:20:33  <GitHub162> [bitcoin] laanwj closed pull request #7187: Keep reorgs fast for SequenceLocks checks (master...fastReorgBIP68) https://github.com/bitcoin/bitcoin/pull/7187
336 2016-03-16T20:32:53  <btcdrak> The mempool behaviours for BIP68/112 have been backported by cherry-pick to 0.11 and 0.12 in PRs #7543, #7695 and #7693. Can I ask a few eyes you verify they are correct.
337 2016-03-16T20:38:37  *** achow101 has joined #bitcoin-core-dev
338 2016-03-16T20:44:31  *** laurentmt has quit IRC
339 2016-03-16T21:23:54  *** Don_John has joined #bitcoin-core-dev
340 2016-03-16T21:47:51  *** Guyver2 has quit IRC
341 2016-03-16T22:01:47  *** randy-waterhouse has joined #bitcoin-core-dev
342 2016-03-16T22:30:35  *** BashCo_ has joined #bitcoin-core-dev
343 2016-03-16T22:33:02  *** BashCo has quit IRC
344 2016-03-16T22:43:20  *** Thireus has quit IRC
345 2016-03-16T22:43:38  *** Thireus has joined #bitcoin-core-dev
346 2016-03-16T22:58:21  *** PRab has joined #bitcoin-core-dev
347 2016-03-16T23:00:02  *** Thireus has quit IRC
348 2016-03-16T23:01:04  *** Chris_Stewart_5 has quit IRC
349 2016-03-16T23:11:09  *** MarcoFalke has joined #bitcoin-core-dev
350 2016-03-16T23:17:55  *** wallet421 has quit IRC
351 2016-03-16T23:34:28  *** wallet42 has joined #bitcoin-core-dev
352 2016-03-16T23:46:57  *** belcher has joined #bitcoin-core-dev
353 2016-03-16T23:47:14  *** MarcoFalke has quit IRC
354 2016-03-16T23:55:27  *** laurentmt has joined #bitcoin-core-dev