1 2017-01-26T00:03:48  *** MarcoFalke has joined #bitcoin-core-dev
  2 2017-01-26T00:11:38  *** Alina-malina has quit IRC
  3 2017-01-26T00:12:36  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b68f898efa09...f89502306dcf
  4 2017-01-26T00:12:36  <bitcoin-git> bitcoin/master 2f10f06 Suhas Daftuar: qa: Increase a sync_blocks timeout in pruning.py
  5 2017-01-26T00:12:37  <bitcoin-git> bitcoin/master f895023 MarcoFalke: Merge #9628: qa: Increase a sync_blocks timeout in pruning.py...
  6 2017-01-26T00:12:55  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9628: qa: Increase a sync_blocks timeout in pruning.py (master...2017-01-longer-pruning-sync) https://github.com/bitcoin/bitcoin/pull/9628
  7 2017-01-26T00:14:13  *** Saucery has quit IRC
  8 2017-01-26T00:17:38  *** Alina-malina has joined #bitcoin-core-dev
  9 2017-01-26T00:42:55  *** Alina-malina has quit IRC
 10 2017-01-26T00:49:11  <bitcoin-git> [bitcoin] jtimon opened pull request #9634: Fail in DecodeHexTx if there is extra data at the end (master...upstream-fail-decode-tx) https://github.com/bitcoin/bitcoin/pull/9634
 11 2017-01-26T00:52:35  *** face has quit IRC
 12 2017-01-26T00:52:53  *** face has joined #bitcoin-core-dev
 13 2017-01-26T00:54:55  *** MarcoFalke has quit IRC
 14 2017-01-26T00:57:28  *** abpa has quit IRC
 15 2017-01-26T00:58:15  *** Alina-malina has joined #bitcoin-core-dev
 16 2017-01-26T01:00:05  *** AaronvanW has quit IRC
 17 2017-01-26T01:13:15  *** oven has quit IRC
 18 2017-01-26T01:14:15  *** oven has joined #bitcoin-core-dev
 19 2017-01-26T01:27:30  *** Ylbam has quit IRC
 20 2017-01-26T01:37:15  *** waxwing has joined #bitcoin-core-dev
 21 2017-01-26T01:51:05  *** To7 has quit IRC
 22 2017-01-26T02:01:13  *** AaronvanW has joined #bitcoin-core-dev
 23 2017-01-26T02:05:57  *** AaronvanW has quit IRC
 24 2017-01-26T02:19:20  *** echonaut2 has joined #bitcoin-core-dev
 25 2017-01-26T02:20:49  *** echonaut has quit IRC
 26 2017-01-26T02:55:17  *** nanotube has quit IRC
 27 2017-01-26T03:09:41  *** nanotube has joined #bitcoin-core-dev
 28 2017-01-26T03:28:43  *** moli has quit IRC
 29 2017-01-26T03:33:19  *** Pat_Boy has joined #bitcoin-core-dev
 30 2017-01-26T03:33:23  *** PatBoy has quit IRC
 31 2017-01-26T03:33:23  *** Pat_Boy is now known as PatBoy
 32 2017-01-26T04:03:51  *** shesek has quit IRC
 33 2017-01-26T04:04:21  *** chris2000 has joined #bitcoin-core-dev
 34 2017-01-26T04:07:20  *** chris200_ has quit IRC
 35 2017-01-26T04:16:35  *** moli has joined #bitcoin-core-dev
 36 2017-01-26T04:26:30  *** jtimon has quit IRC
 37 2017-01-26T04:54:22  *** kadoban has quit IRC
 38 2017-01-26T05:01:46  *** paracyst_ has joined #bitcoin-core-dev
 39 2017-01-26T05:02:30  *** paracyst has quit IRC
 40 2017-01-26T05:48:20  <gmaxwell> cfields: re your earlier question-- show me the code. I'm unsure about matt's suggestion because I can read it in ways that wouldn't be good.  E.g. if the recieve for a verack unconditionally set fsuccessfullyconnected true then something that veracked without ever going through version could be successfully connected.
 41 2017-01-26T05:48:31  <gmaxwell> assuming that it doesn't do anything stupid, it's fine
 42 2017-01-26T05:48:51  <gmaxwell> and I think it would be fine to clamp down the handshake and require the states be followed as expected...
 43 2017-01-26T05:49:07  <gmaxwell> not just fine but good: I could imagine us having some uninitlized something as a result of getting that wrong.
 44 2017-01-26T05:50:06  <gmaxwell> cfields: but I will gladly review whatever comes up when it comes up.
 45 2017-01-26T05:57:33  *** cryptapus_afk has quit IRC
 46 2017-01-26T06:20:50  *** cannon-c has joined #bitcoin-core-dev
 47 2017-01-26T06:55:05  *** Cory has quit IRC
 48 2017-01-26T06:55:44  *** cryptapus_afk has joined #bitcoin-core-dev
 49 2017-01-26T06:55:46  *** cryptapus_afk has joined #bitcoin-core-dev
 50 2017-01-26T06:56:58  *** Pasha has joined #bitcoin-core-dev
 51 2017-01-26T06:59:08  *** Ylbam has joined #bitcoin-core-dev
 52 2017-01-26T07:03:52  *** Pasha is now known as Cory
 53 2017-01-26T07:14:27  *** AaronvanW has joined #bitcoin-core-dev
 54 2017-01-26T07:14:27  *** AaronvanW has joined #bitcoin-core-dev
 55 2017-01-26T07:18:49  *** AaronvanW has quit IRC
 56 2017-01-26T07:26:50  *** cryptapus_afk has quit IRC
 57 2017-01-26T07:29:07  *** Alina-malina has quit IRC
 58 2017-01-26T07:29:08  *** Alina-malina has joined #bitcoin-core-dev
 59 2017-01-26T07:56:41  *** cryptapus_afk has joined #bitcoin-core-dev
 60 2017-01-26T07:56:42  *** cryptapus_afk has joined #bitcoin-core-dev
 61 2017-01-26T08:07:37  *** BashCo has quit IRC
 62 2017-01-26T08:15:36  *** AaronvanW has joined #bitcoin-core-dev
 63 2017-01-26T08:20:10  *** AaronvanW has quit IRC
 64 2017-01-26T08:29:24  *** BashCo has joined #bitcoin-core-dev
 65 2017-01-26T08:42:05  *** paveljanik has quit IRC
 66 2017-01-26T08:42:20  *** JackH has joined #bitcoin-core-dev
 67 2017-01-26T08:43:53  *** paveljanik has joined #bitcoin-core-dev
 68 2017-01-26T08:45:47  *** waxwing has quit IRC
 69 2017-01-26T08:47:21  *** justanotheruser has quit IRC
 70 2017-01-26T08:56:45  *** devinbit123 has joined #bitcoin-core-dev
 71 2017-01-26T08:58:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f89502306dcf...3f9f9629cc1e
 72 2017-01-26T08:58:13  <bitcoin-git> bitcoin/master 99464bc Suhas Daftuar: net: Consistently use GetTimeMicros() for inactivity checks...
 73 2017-01-26T08:58:14  <bitcoin-git> bitcoin/master 3f9f962 Wladimir J. van der Laan: Merge #9606: net: Consistently use GetTimeMicros() for inactivity checks...
 74 2017-01-26T08:58:33  <bitcoin-git> [bitcoin] laanwj closed pull request #9606: net: Consistently use GetTimeMicros() for inactivity checks (master...2017-01-net-time-comparisons) https://github.com/bitcoin/bitcoin/pull/9606
 75 2017-01-26T08:59:58  *** justanotheruser has joined #bitcoin-core-dev
 76 2017-01-26T09:04:32  *** arubi has quit IRC
 77 2017-01-26T09:04:46  *** arubi has joined #bitcoin-core-dev
 78 2017-01-26T09:05:06  *** waxwing has joined #bitcoin-core-dev
 79 2017-01-26T09:05:58  *** CubicEarth has joined #bitcoin-core-dev
 80 2017-01-26T09:12:30  *** shesek has joined #bitcoin-core-dev
 81 2017-01-26T09:16:10  *** AaronvanW has joined #bitcoin-core-dev
 82 2017-01-26T09:16:11  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f9f9629cc1e...07421cf2a7cf
 83 2017-01-26T09:16:12  <bitcoin-git> bitcoin/master 5a00659 Russell Yanofsky: [wallet] Clarify getbalance help string to explain interaction with bumpfee...
 84 2017-01-26T09:16:13  <bitcoin-git> bitcoin/master 07421cf Wladimir J. van der Laan: Merge #9613: [wallet] Clarify getbalance help string to explain interaction with bumpfee...
 85 2017-01-26T09:16:37  *** Guyver2 has joined #bitcoin-core-dev
 86 2017-01-26T09:16:46  <bitcoin-git> [bitcoin] laanwj closed pull request #9613: [wallet] Clarify getbalance help string to explain interaction with bumpfee (master...pr/getbalance-help) https://github.com/bitcoin/bitcoin/pull/9613
 87 2017-01-26T09:16:56  <bitcoin-git> [bitcoin] laanwj closed pull request #9587: Do not shadow local variable named `tx`. (master...20170119_Wshadow_net_processing) https://github.com/bitcoin/bitcoin/pull/9587
 88 2017-01-26T09:20:47  *** AaronvanW has quit IRC
 89 2017-01-26T09:22:10  *** MarcoFalke has joined #bitcoin-core-dev
 90 2017-01-26T09:31:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/10dc58a2aa79...5ac668759ded
 91 2017-01-26T09:31:25  <bitcoin-git> bitcoin/master c36ec71 Cory Fields: depends: qt: disable printer for all platforms, not just osx...
 92 2017-01-26T09:31:26  <bitcoin-git> bitcoin/master 5ac6687 Wladimir J. van der Laan: Merge #9574: [depends] Fix QT build on OSX...
 93 2017-01-26T09:31:38  <bitcoin-git> [bitcoin] laanwj closed pull request #9574: [depends] Fix QT build on OSX (master...fix-osx-depends-build) https://github.com/bitcoin/bitcoin/pull/9574
 94 2017-01-26T09:32:20  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5ac668759ded...fd7021142a7a
 95 2017-01-26T09:32:20  <bitcoin-git> bitcoin/master 8ff8d21 Gregory Maxwell: Send final alert message to older peers after connecting....
 96 2017-01-26T09:32:21  <bitcoin-git> bitcoin/master fd70211 Wladimir J. van der Laan: Merge #9594: Send final alert message to older peers after connecting....
 97 2017-01-26T09:32:35  <bitcoin-git> [bitcoin] laanwj closed pull request #9594: Send final alert message to older peers after connecting. (master...send_final_alert) https://github.com/bitcoin/bitcoin/pull/9594
 98 2017-01-26T09:42:10  <gmaxwell> hurrah.
 99 2017-01-26T09:47:03  *** cryptapus_afk has quit IRC
100 2017-01-26T09:51:11  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9623: fixing typo in README (master...patch-14) https://github.com/bitcoin/bitcoin/pull/9623
101 2017-01-26T09:53:37  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd7021142a7a...9b4d2673b775
102 2017-01-26T09:53:37  <bitcoin-git> bitcoin/master de1ae32 Alex Morcos: Exclude RBF txs from fee estimation
103 2017-01-26T09:53:38  <bitcoin-git> bitcoin/master 9b4d267 Wladimir J. van der Laan: Merge #9519: Exclude RBF replacement txs from fee estimation...
104 2017-01-26T09:53:52  <bitcoin-git> [bitcoin] laanwj closed pull request #9519: Exclude RBF replacement txs from fee estimation (master...excludeRBF) https://github.com/bitcoin/bitcoin/pull/9519
105 2017-01-26T09:55:05  *** cryptapus_afk has joined #bitcoin-core-dev
106 2017-01-26T10:13:18  *** Guyver2 has quit IRC
107 2017-01-26T10:16:57  *** AaronvanW has joined #bitcoin-core-dev
108 2017-01-26T10:21:26  *** AaronvanW has quit IRC
109 2017-01-26T10:26:49  *** AaronvanW has joined #bitcoin-core-dev
110 2017-01-26T10:36:39  *** MarcoFalke has quit IRC
111 2017-01-26T10:56:48  *** wvr has joined #bitcoin-core-dev
112 2017-01-26T11:05:14  *** chjj has quit IRC
113 2017-01-26T11:05:38  *** chjj has joined #bitcoin-core-dev
114 2017-01-26T11:14:18  *** BashCo has quit IRC
115 2017-01-26T11:14:24  *** BashCo_ has joined #bitcoin-core-dev
116 2017-01-26T11:26:40  *** laurentmt has joined #bitcoin-core-dev
117 2017-01-26T11:27:55  *** laurentmt has quit IRC
118 2017-01-26T11:32:49  *** 7F1AAKHX0 is now known as jeremias
119 2017-01-26T11:39:18  *** whphhg has quit IRC
120 2017-01-26T11:50:41  *** Guyver2 has joined #bitcoin-core-dev
121 2017-01-26T12:24:46  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9637: [Qt] fix transaction details output-index to reflect vout index (master...2017/01/qt_vout) https://github.com/bitcoin/bitcoin/pull/9637
122 2017-01-26T12:54:15  *** whphhg has joined #bitcoin-core-dev
123 2017-01-26T13:18:23  *** whphhg has left #bitcoin-core-dev
124 2017-01-26T13:24:49  *** shesek has quit IRC
125 2017-01-26T13:38:20  *** shesek has joined #bitcoin-core-dev
126 2017-01-26T13:47:54  *** Sosumi has joined #bitcoin-core-dev
127 2017-01-26T13:59:19  *** arubi has quit IRC
128 2017-01-26T14:01:48  *** arubi has joined #bitcoin-core-dev
129 2017-01-26T14:10:08  *** cannon-c has quit IRC
130 2017-01-26T14:12:58  *** kadoban has joined #bitcoin-core-dev
131 2017-01-26T14:36:06  *** Cheeseo has joined #bitcoin-core-dev
132 2017-01-26T14:36:07  *** Cheeseo has joined #bitcoin-core-dev
133 2017-01-26T14:43:51  *** jtimon has joined #bitcoin-core-dev
134 2017-01-26T14:47:34  *** Chris_Stewart_5 has quit IRC
135 2017-01-26T14:55:26  *** MarcoFalke has joined #bitcoin-core-dev
136 2017-01-26T14:59:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
137 2017-01-26T15:02:31  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9638: qa: Actually test assertions in pruning.py (master...Mf1701-qaPruning_try) https://github.com/bitcoin/bitcoin/pull/9638
138 2017-01-26T15:04:17  *** MarcoFalke has quit IRC
139 2017-01-26T15:04:27  *** MarcoFalke has joined #bitcoin-core-dev
140 2017-01-26T15:16:10  *** RoyceX has joined #bitcoin-core-dev
141 2017-01-26T15:19:22  *** Cheeseo has quit IRC
142 2017-01-26T15:43:14  *** achow101 has quit IRC
143 2017-01-26T15:44:31  *** achow101 has joined #bitcoin-core-dev
144 2017-01-26T16:09:18  *** BashCo_ has quit IRC
145 2017-01-26T16:11:29  *** devinbit123 has quit IRC
146 2017-01-26T16:28:53  *** BashCo has joined #bitcoin-core-dev
147 2017-01-26T16:42:30  *** arubi has quit IRC
148 2017-01-26T16:49:37  *** abpa has joined #bitcoin-core-dev
149 2017-01-26T17:01:10  *** moli has quit IRC
150 2017-01-26T17:02:38  *** moli_ has joined #bitcoin-core-dev
151 2017-01-26T17:10:29  *** bsm117532 has quit IRC
152 2017-01-26T17:12:27  *** bsm117532 has joined #bitcoin-core-dev
153 2017-01-26T17:28:20  *** testtesttest has joined #bitcoin-core-dev
154 2017-01-26T17:55:47  *** paracyst_ has quit IRC
155 2017-01-26T17:58:49  *** paracyst has joined #bitcoin-core-dev
156 2017-01-26T18:17:33  *** waxwing has quit IRC
157 2017-01-26T18:21:22  *** justanotheruser has quit IRC
158 2017-01-26T18:21:56  *** aalex has quit IRC
159 2017-01-26T18:23:54  *** MarcoFalke has quit IRC
160 2017-01-26T18:24:11  *** MarcoFalke has joined #bitcoin-core-dev
161 2017-01-26T18:29:05  *** waxwing has joined #bitcoin-core-dev
162 2017-01-26T18:54:17  <instagibbs> meeting in 6 minutes
163 2017-01-26T18:54:19  <jtimon> a fast question before the meeting...I did the gitian builds as described in the manual, but didn't sign them yet, it is expected that I create a new gpg key only to sign gitian builds or that I reuse my own?
164 2017-01-26T18:54:39  <instagibbs> jtimon, I don't know if there's expectation, but it's pretty common yeah
165 2017-01-26T18:54:44  <instagibbs> make a subkey
166 2017-01-26T18:55:17  <achow101> jtimon: I don't think it matters. I have been using my own key
167 2017-01-26T18:55:17  <wumpus> I just use my own
168 2017-01-26T18:55:41  <sipa> I just use my own
169 2017-01-26T18:55:46  <instagibbs> wumpus, o_0 crap I recall you using another key that you've signed. Maybe im delusional
170 2017-01-26T18:56:16  <achow101> instagibbs: maybe you are thinking of the release key?
171 2017-01-26T18:56:24  <instagibbs> ah, that might be it
172 2017-01-26T18:56:50  <jtimon> well, my gpg key has 2 subkeys for signing already, but they're in yubikey, not in the VM, I guess I can copy my ~/.gnupg to the VM and then see how I can use the yubikey from the VM, thanks everyone
173 2017-01-26T18:56:52  <wumpus> though generally it's best to keep things separated, a subkey sounds like the right thing to do, but I haven't got around to figuring out how that gpg functionality works
174 2017-01-26T18:57:12  <instagibbs> http://pgp.mit.edu/pks/lookup?op=vindex&search=0x90C8019E36C2E964 yes the release key
175 2017-01-26T18:57:26  <wumpus> yes the releases are signed with a different key, that key only signs releases, not git commits or gitian asserts
176 2017-01-26T18:57:26  <achow101> jtimon: you can copy the assert files out and sign them
177 2017-01-26T18:57:32  <instagibbs> I had a key on my VM, then managed to lose it, so not really much better :/
178 2017-01-26T18:57:53  <wumpus> yes, I do that too, copy the assert files after build and sign them on another machine
179 2017-01-26T18:58:10  <instagibbs> achow101, should have thought of that earlier, heh
180 2017-01-26T18:58:24  <jtimon> achow101: I guess that's another option, but not running ./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml as in https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#build-and-sign-bitcoin-core-for-linux-windows-and-os-x I assume
181 2017-01-26T18:58:42  <instagibbs> does the gsign stuff just point to the right assert file?
182 2017-01-26T18:58:59  <instagibbs> ie just copy and do signature like normal, it will validate via gitian script?
183 2017-01-26T18:59:40  <wumpus> well you still do gsign, but you pass an option to not do the final gpg stop
184 2017-01-26T18:59:46  <achow101> just gpg --detach-sign normally to sign it.
185 2017-01-26T18:59:56  <achow101> gsign just makes the assert files AFAIK
186 2017-01-26T19:00:10  <MarcoFalke> dingding
187 2017-01-26T19:00:12  <sipa> DONG
188 2017-01-26T19:00:12  <instagibbs> kk, thanks for explanation, will do for next release
189 2017-01-26T19:00:15  <wumpus> I don't know by heart what that option is, it used to be passing a dummy 'true' as gpg parameter
190 2017-01-26T19:00:21  <instagibbs> I'll figure it out
191 2017-01-26T19:00:21  <wumpus> #startmeeting
192 2017-01-26T19:00:21  <lightningbot> Meeting started Thu Jan 26 19:00:21 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
193 2017-01-26T19:00:21  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
194 2017-01-26T19:00:34  <jonasschnelli> hi
195 2017-01-26T19:00:36  <instagibbs> (actually would be a useful optional step in gitian guide)
196 2017-01-26T19:00:37  <wumpus> and yes on thesigning side you do gpg --detach-sign, no need for gitian there at all
197 2017-01-26T19:00:55  <wumpus> yes the gitian guide mentions signing externally but I'm not sure it says how to do that
198 2017-01-26T19:01:28  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
199 2017-01-26T19:01:45  <instagibbs> oops, https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#signing-externally
200 2017-01-26T19:01:51  <instagibbs> jtimon, ^^ ok now meeting sorry
201 2017-01-26T19:01:56  <kanzure> hi.
202 2017-01-26T19:01:57  <wumpus> proposed topics?
203 2017-01-26T19:02:15  <jtimon> instagibbs: np, got good answers already
204 2017-01-26T19:02:33  <sipa> if people don't shoot me for it, i'd like to briefly bring up coding style
205 2017-01-26T19:02:40  <wumpus> bleh
206 2017-01-26T19:02:57  *** arubi has joined #bitcoin-core-dev
207 2017-01-26T19:03:00  <jtimon> if there's no other topic, I don't see why not
208 2017-01-26T19:03:03  <instagibbs> how about just a grazing flesh wound
209 2017-01-26T19:03:38  <wumpus> but yes there's no other proposals so go ahead
210 2017-01-26T19:03:41  <MarcoFalke> If morcos is around, we could make a short topic on how to get the priority patch merged. (Seems to bit rot fast)
211 2017-01-26T19:03:50  <wumpus> #topic coding style
212 2017-01-26T19:04:36  <sipa> it seems that we're not really asking people to stick to particular coding style, and that sometimes leads to unclarities "what style should i use here?"
213 2017-01-26T19:04:38  <BlueMatt> ugh
214 2017-01-26T19:04:40  *** arubi has quit IRC
215 2017-01-26T19:04:55  <morcos> i'm here..  i'm happy to worry about that after 0.14
216 2017-01-26T19:04:57  <MarcoFalke> just use clang-format-diff.py *hides*
217 2017-01-26T19:05:03  <jonasschnelli> MarcoFalke: +1
218 2017-01-26T19:05:12  <instagibbs> sipa, I copy the code around me :P
219 2017-01-26T19:05:14  <jtimon> the answer is https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format no?
220 2017-01-26T19:05:17  <sipa> and i think that the "mimick the surrounding code" advice we've been following is a bad idea
221 2017-01-26T19:05:30  <wumpus> I don't really see the point in spending more energy on this
222 2017-01-26T19:05:34  <sipa> it doesn't actually help in making the codebase converge (which i think is goal)
223 2017-01-26T19:05:43  <jonasschnelli> I once proposed that, but everyone was against that. A CI check for clang style. We can still accept it... and could be something different then travis.
224 2017-01-26T19:05:52  <jtimon> but yeah, since it's not done automatically project wise I often violate it without noticing
225 2017-01-26T19:05:54  <MarcoFalke> Just format the diff on every patch and we will converge eventually.
226 2017-01-26T19:06:03  <sipa> i'm not suggesting we go fix everything at once
227 2017-01-26T19:06:11  <wumpus> I think mimicing the surrounding code is a good thing, usually, as long as you don't introduce really crappy looking lines well I won't hold up merging on a few code style nits
228 2017-01-26T19:06:21  <morcos> wumpus: i do think it would be nice if we were at least slowly converging on a common code style... i think we are making small progress..  for instance now i know to always brace my if's and i don't mind if someone points out that i forget it
229 2017-01-26T19:06:28  <jtimon> MarcoFalke: IIRC there was a python script to do that automatically
230 2017-01-26T19:06:33  <BlueMatt> jonasschnelli: I'm opposed to a CI check for clang style...I'm in favor of a bot which auto-opens a pr which fixes clang style on recently-broken PRs
231 2017-01-26T19:06:43  <wumpus> morcos: yes, always using braces makes sense from a security/correctness point of view
232 2017-01-26T19:06:43  <MarcoFalke> jtimon: Yes I commited those :)
233 2017-01-26T19:06:44  <jtimon> or something similar, but I've never used it
234 2017-01-26T19:06:45  <morcos> what is annoying is when you don't know what you're supposed to do, and then something is pointed out to you and you feel like its just a difference in taaste
235 2017-01-26T19:07:07  <sipa> right - my goal is to make the codebase converge
236 2017-01-26T19:07:10  <wumpus> but some other things, meh
237 2017-01-26T19:07:14  <BlueMatt> sipa: yes, that would be nice
238 2017-01-26T19:07:21  <wumpus> it usually *is* a  difference in taste
239 2017-01-26T19:07:24  <sipa> not necessarily fast, and not necessarily to whatever my own personal preference is
240 2017-01-26T19:07:31  <jtimon> MarcoFalke: right, so I think if we all use that, as you say we will eventually converge (or be close enough that is not a big deal to do the remaining stuff all at once)
241 2017-01-26T19:07:38  <sipa> but i'd like to get an agreement that the goal is converging
242 2017-01-26T19:07:50  * BlueMatt votes for coding-style-recent-pr-fixup bog
243 2017-01-26T19:07:51  <BlueMatt> bot
244 2017-01-26T19:08:04  <wumpus> as I said, I don't really see the point of spending much energy on this. There are tons of real issue
245 2017-01-26T19:08:05  <BlueMatt> that way none of us have to think about it, but it still happens :)
246 2017-01-26T19:08:16  <morcos> i'm +1 on converging to someone's taste.  i don't much care whose, as long as there is an answer that doesn't depend on who you ask
247 2017-01-26T19:08:20  <wumpus> I don't want to see even more 'massage around a few characters idly' pulls
248 2017-01-26T19:08:29  <jtimon> what about just a check in travis or something?
249 2017-01-26T19:08:33  <wumpus> no.
250 2017-01-26T19:08:39  <MarcoFalke> jtimon: We don't want travis to fail due to style
251 2017-01-26T19:08:39  <paveljanik> I'm in favour of slow non-forced (no-CI) convergence.
252 2017-01-26T19:08:47  <wumpus> travis should check correctness
253 2017-01-26T19:08:53  <instagibbs> Can we at least have a cultural push towards one? I don't care which.
254 2017-01-26T19:08:58  <wumpus> if travis fails due to style, it will always be broken, believe me
255 2017-01-26T19:09:00  <sipa> instagibbs: +1
256 2017-01-26T19:09:01  <BlueMatt> yes, no travis-says-no-for-garbage-reasons
257 2017-01-26T19:09:14  <MarcoFalke> But we might add a non-voting other-than-travis ci, if that is possible?
258 2017-01-26T19:09:24  <wumpus> I don't want to block pulls on stupid style issues
259 2017-01-26T19:09:32  <BlueMatt> wumpus: yes, very much that
260 2017-01-26T19:09:34  <wumpus> there are already enough valid reasons to hold up pulls for months
261 2017-01-26T19:09:37  <wumpus> please
262 2017-01-26T19:09:41  <wumpus> focus on important stuff
263 2017-01-26T19:09:43  <jtimon> wumpus: right, it would be only on style on the newly modified code, but yeah, it seems it could fail when we don't want it to
264 2017-01-26T19:10:28  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
265 2017-01-26T19:10:40  <jtimon> anyway, the bot could just nit open prs instead of fixing things by himself
266 2017-01-26T19:10:42  <BlueMatt> the only coding style issue I'd be ok with travis complaining about is bad indentation
267 2017-01-26T19:10:43  <morcos> sipa, or anyone else that has an opinon on coding style.. if you'd like to get people to move to your style on any specific thing, i think you need to get your request merged to developer-notes
268 2017-01-26T19:10:45  <BlueMatt> because that leads to bugs
269 2017-01-26T19:10:58  <sipa> maybe what i'm after is being able to ask people (as a non-blocking nit, even) to fix style issue, without it being seen as "forcing your personal opinion"
270 2017-01-26T19:11:05  <wumpus> I say if there's use of coding style that is known to introduce bugs (such as unbraced conditionals) there's a point to pointing it out
271 2017-01-26T19:11:18  <morcos> if its in there, i think its fair game for pointing out not meeting it...  if its not in there.. well come on
272 2017-01-26T19:11:27  <BlueMatt> jtimon: people already complain about endless nits when they show up for the first time to contribute...I'm ok with my own prs getting that, but not people trying to do one-offs
273 2017-01-26T19:11:30  <sipa> morcos: of course, only for things in the style guide
274 2017-01-26T19:11:40  <wumpus> morcos: yes, it should certainly be documented in that file
275 2017-01-26T19:11:45  * jtimon wonders if this is the right time to indent CheckTxInputs
276 2017-01-26T19:11:58  <wumpus> if it's not in there there's no basis for pointing it out
277 2017-01-26T19:12:11  <morcos> we are all talking about NEW code...  but jtimon brings up a good point...
278 2017-01-26T19:12:26  <sipa> a move-only commit should probably not change style
279 2017-01-26T19:12:35  <morcos> for instance i have a couple of recent PR's that add braces without changing indentation....
280 2017-01-26T19:12:44  <sipa> about that:
281 2017-01-26T19:12:47  <wumpus> eh, indeed, that makes it harder to check whether it's mov only
282 2017-01-26T19:12:58  <sipa> git diff -w, git blame -w, git show -w, ...
283 2017-01-26T19:13:03  <morcos> i thought thats what people preferred...  but i'm happy to add the indentation if people can figure out how to ignore the white space changes
284 2017-01-26T19:13:05  <gmaxwell> changing style though should result in the same object files.
285 2017-01-26T19:13:16  <sipa> and even github supports whitespace ignoring diffs, add ?w=1 to the URL
286 2017-01-26T19:13:18  <wumpus> gmaxwell: definitely
287 2017-01-26T19:13:22  <morcos> ok... good wiht me.. i just thought people wanted differently b/c of similar examples in the codebase
288 2017-01-26T19:13:24  <BlueMatt> sipa: you meant -b
289 2017-01-26T19:13:31  <wumpus> gmaxwell: that means adding/removing no empty lines though
290 2017-01-26T19:13:36  <wumpus> gmaxwell: because line numbers
291 2017-01-26T19:13:53  <instagibbs> do we have a style guide already?
292 2017-01-26T19:13:58  <instagibbs> "if" braces even
293 2017-01-26T19:14:00  <wumpus> instagibbs: you don't know?
294 2017-01-26T19:14:04  <jtimon> yeah, regarding CheckTxInputs I believe I was asked to wait after moving it for indenting ages ago or something, but yeah, didn't know -w and that's more reason not to wait for anything (specially moves that may never happen)
295 2017-01-26T19:14:09  <BlueMatt> wumpus: I think lots of people dont...
296 2017-01-26T19:14:11  <gmaxwell> I think we should avoid changing indents spairingly. And then fix it not long after.
297 2017-01-26T19:14:13  <sipa> instagibbs: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md
298 2017-01-26T19:14:15  <instagibbs> wumpus, I'm here to ask the dumb questions
299 2017-01-26T19:15:00  <gmaxwell> the developer nodes style guide isn't much of a style guide (not a complaint), and its more of one recently, but I don't normally consider it the place to go to figure out how to format something. :)
300 2017-01-26T19:15:14  <wumpus> BlueMatt: we refer to it in CONTRIBUTING.md, which automatically gets linked if you submit a PR
301 2017-01-26T19:15:38  <wumpus> gmaxwell: it's not supposed to have a lot of formatting guidelines, just basic ones
302 2017-01-26T19:15:40  <sipa> gmaxwell: i'm perfectly fine restricting my style nits to things that are in that file
303 2017-01-26T19:15:40  <BlueMatt> wumpus: I believe only for issues - I've never seen it for PRs
304 2017-01-26T19:15:47  <BlueMatt> but, ok, fair
305 2017-01-26T19:16:13  <wumpus> it mentions the "always use braces" though
306 2017-01-26T19:16:22  <jtimon> right, I believe we should try to avoid style nits that we don't have documented
307 2017-01-26T19:16:37  * BlueMatt thinks the endless "add braces here" comments in the past month got kinda annoying for a while
308 2017-01-26T19:16:46  <wumpus> definitely. In general please try to not cloud out serious discussion with lots of style nits
309 2017-01-26T19:16:54  <BlueMatt> agree with them, but annoying
310 2017-01-26T19:16:58  <jonasschnelli> wumpus: thats a very good point
311 2017-01-26T19:17:01  <wumpus> BlueMatt: that's my point ^^
312 2017-01-26T19:17:04  <jtimon> and by documented I'm fine counting https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format
313 2017-01-26T19:17:10  <BlueMatt> wumpus: yes, just agreeing, I suppose :)
314 2017-01-26T19:17:28  <MarcoFalke> We should just raise awareness that there is a script to do the formatting for you.
315 2017-01-26T19:17:30  <sipa> yeah, no point in "add braces here" and "and here!" and "and here also!" comments all over the place, i guess
316 2017-01-26T19:17:35  <MarcoFalke> No need to spam pull requests
317 2017-01-26T19:17:39  <gmaxwell> Peopel should say if it bothers them, but my expirence is that small things like that improve moral in development teams.  It's an oppturnity to help each other which is very easy and clear. Not "please totally redesign your patch". :)
318 2017-01-26T19:17:52  <gmaxwell> people*
319 2017-01-26T19:18:12  <jtimon> MarcoFalke: right, althought the bot that runs the script for you and complains in your PR sounds like a good idea to me
320 2017-01-26T19:18:21  <gmaxwell> At least I find it gratifying to go, fixed, fixed, fixed, fixed.. and now the patch is awesome hurray and thanks for your help. :)
321 2017-01-26T19:18:27  <sipa> enough said on the topic, as far as i'm concerned
322 2017-01-26T19:18:31  <instagibbs> sipa, feel free to propose a "non blocking, non-nitting" style
323 2017-01-26T19:18:35  <instagibbs> :P
324 2017-01-26T19:18:40  <MarcoFalke> #action PSA Use clang-format-diff.py before submitting a patch, whenever possible.
325 2017-01-26T19:18:58  <wumpus> gmaxwell: sure, as long as it's not overly pedantic, and doesn't continue time after time. e.g. you're just about to merge something and a new screenful of style nits appears
326 2017-01-26T19:19:08  <gmaxwell> MarcoFalke: is there instructions on that? also does it know about our new brace requirements?
327 2017-01-26T19:19:25  <wumpus> morcos: good advice I suppose, should go into CONTRIBUTING.md
328 2017-01-26T19:19:30  <sipa> wumpus: so how about treating style always as non-blocking (for the person deciding to merge)
329 2017-01-26T19:19:34  <MarcoFalke> #action fix clang-format https://github.com/bitcoin/bitcoin/pull/9506#issuecomment-271727718
330 2017-01-26T19:19:45  <jtimon> we can always ignore the bot in certain cases if it makes sense
331 2017-01-26T19:19:52  <MarcoFalke> gmaxwell: There should be a doc in /contrib/dev-tools, no?
332 2017-01-26T19:20:13  <wumpus> yes there is documentation on how to use it
333 2017-01-26T19:20:26  * wumpus wonders if there is still so much differnce between clang versions, for recent versions
334 2017-01-26T19:20:37  <gmaxwell> MarcoFalke:  I dunno, never used that tool before. it's not mentioned in contributing.md.
335 2017-01-26T19:20:37  <wumpus> I mean in how clang-format formats
336 2017-01-26T19:21:04  <jtimon> right, we need to use the same version
337 2017-01-26T19:21:11  <gmaxwell> yea, I'm willing to install a specific version of clang for this-- as most of us should be... but just something to keep in mind for random contributors from the interwebs.
338 2017-01-26T19:21:16  <MarcoFalke> wumpus: Last time I checked there were no diffs, but it was a year ago or so.
339 2017-01-26T19:21:56  <wumpus> gmaxwell: well it's very possible that it stabilized, it's less important for format-patch than when requiring a reformat of the whole source, then it will oscillate :p
340 2017-01-26T19:22:02  <MarcoFalke> But it should not matter for 99.9% of the code.
341 2017-01-26T19:22:35  *** belcher has quit IRC
342 2017-01-26T19:22:36  <wumpus> anyhow, other topics?
343 2017-01-26T19:23:16  <sipa> how are we on 0.14 bugs?
344 2017-01-26T19:23:45  <gmaxwell> All bugs are features, hurray.
345 2017-01-26T19:23:54  <morcos> i have one more that needs tagging 0.14.. and i think sdaftuar has 1-2 coming
346 2017-01-26T19:24:13  <wumpus> #topic bug-fixing for 0.14
347 2017-01-26T19:24:18  <morcos> they are all kind of minor fixups for bumpfee or replacement type stuff... mostly edge cases.. nothing serious
348 2017-01-26T19:24:32  <MarcoFalke> morcos: I think the one you want to tag is more a feature than a bug fix. At some point we need to draw the line and release.
349 2017-01-26T19:24:40  <morcos> please tag #9615
350 2017-01-26T19:24:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub
351 2017-01-26T19:24:53  <MarcoFalke> But the one that is tagged right now should be merged as bug fix
352 2017-01-26T19:25:09  <achow101> I have a bug-fix (I think) for decoderawtx rpc
353 2017-01-26T19:25:13  <morcos> MarcoFalke: well its a bug fix b/c if we ever do a release without having a more conservative wallet incremental fee, then we are screwed for ever incrementing it
354 2017-01-26T19:25:22  <morcos> this has bit us in the past with dust fees
355 2017-01-26T19:25:24  <wumpus> tagged
356 2017-01-26T19:25:39  <jtimon> reminder, there's currently 6 open prs for 0.14.0: 9638 9626 9622 9609 9589 9108
357 2017-01-26T19:25:39  <morcos> its also really simple
358 2017-01-26T19:26:33  <morcos> i also mention in there that i think we should increase the incremental fee... that coudl be a topic.. but i realize people might not want to do it this close to release, but at least worth discussing it as a general idea and why..
359 2017-01-26T19:26:47  * BlueMatt is waiting on (needs to review 9609) and then run things in helgrind again...will generate lots of std::atomic changes
360 2017-01-26T19:26:54  <BlueMatt> but they should all be minor/trivial
361 2017-01-26T19:27:07  <gmaxwell> :-/
362 2017-01-26T19:27:12  <morcos> but given that it might already be close to needing to be raised, we have to do 9615
363 2017-01-26T19:27:18  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370
364 2017-01-26T19:27:33  <MarcoFalke> What if we want to increment it to 6000 satoshis in two years, then 0.14 will "fall off" regardless.
365 2017-01-26T19:27:53  <gmaxwell> BlueMatt: if there are helgrind results I am doubtful that sprinking atomics everywhere is usually the right solution. For some things like flags it can be... but if we're hitting helgrind errors it means we've gotten the locking wrong.
366 2017-01-26T19:28:01  <cfields> whoops, lost track of time. here.
367 2017-01-26T19:28:09  <MarcoFalke> But I get your point, I just think it is not a blocker. It could also go into 0.14.1
368 2017-01-26T19:28:24  <morcos> MarcoFalke: yes.. but that is something we will keep in mind if ever changing the default... is how many old versions will become less than optimal..  i don't know any better way to do it... there is a tradeoff
369 2017-01-26T19:28:40  <BlueMatt> gmaxwell: shit like CNode::copyStats...should be trivial, is only used in (effectively) debug info, doesnt matter much
370 2017-01-26T19:28:49  <BlueMatt> gmaxwell: but, yes, otherwise agreed
371 2017-01-26T19:28:51  <morcos> but if it goes in 0.14.1 then 0.14.0 could become broken for bumpfee within a few months...  that seems bad!
372 2017-01-26T19:28:55  <wumpus> gmaxwell: tend to agree, doesn't seem like making everything atomic is the proper way to solve concurrency issues - it just shuts up the warnings, without addressing the root cause
373 2017-01-26T19:29:24  <BlueMatt> wumpus: thats why I never did a pile of PRs to do it :p
374 2017-01-26T19:29:37  <gmaxwell> morcos: oh incremental is just the thing that bumpfee uses but not the acceptance policy (behind on the naming since the split)
375 2017-01-26T19:29:46  <wumpus> that's like putting (unsigned) everywhere to shut up comparisons between signed/unsigned errors without looking at the ranges
376 2017-01-26T19:30:16  <MarcoFalke> gmaxwell: Yes, the goal is to split the wallet default and the relay default.
377 2017-01-26T19:30:18  <wumpus> BlueMatt: yes for statistics it seems harmless
378 2017-01-26T19:30:20  <instagibbs> morcos, I didn't expect people to button-mash bumpfee, but maybe I'm wrong on usage patterns
379 2017-01-26T19:30:22  <morcos> gmaxwell: incremental is the policy,  #9615 introduces a wallet incremental which is higher than the default incremental to future-proof...  not configurable, but maxed with actual incremental
380 2017-01-26T19:30:24  <gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub
381 2017-01-26T19:30:40  <gmaxwell> I would agree that bumpfees behavior should be more conservative. (IMO bumpfee should always increase at least multiple of the prior feerate, not just the incremental, in order to give log() bumps at worst)
382 2017-01-26T19:30:46  <cfields> wumpus: many are net things that have been around forever (CNodeStats). I have some ideas in mind for fixing them post-0.14, but I think the changes will end up being too big for 0.14
383 2017-01-26T19:30:52  <cfields> (re atomics)
384 2017-01-26T19:30:55  <instagibbs> In the case of "I just did it, or est feerate is same, I just want higher" this concern seems real
385 2017-01-26T19:31:09  <wumpus> cfields: right
386 2017-01-26T19:31:26  <morcos> instagibbs: i think its reasonable to expect stuck transaction problems might get considerably worse over the next 6 months...   an improved fee estimation is definitely needed...  but its certainly possible bumpfee will be important.
387 2017-01-26T19:31:28  <wumpus> cfields: forgot for a minute that the topic is fixes for 0.14 :)
388 2017-01-26T19:31:51  <cfields> wumpus: yes, otherwise i'd be yelling about s/int/atomic_int/ too, for sure :)
389 2017-01-26T19:32:14  <morcos> gmaxwell: it by default does a new estimatefee...  it just max's that with a multiple of the increment above to make sure it will pass policy
390 2017-01-26T19:32:29  *** belcher has joined #bitcoin-core-dev
391 2017-01-26T19:33:49  <gmaxwell> morcos: right, I think it should also max with a e.g. 10% increase... so that you don't ever have the issue of needing hundreds of bumps to span a plausable range.  I'm in the weeds here though.
392 2017-01-26T19:33:57  <morcos> this is the first time we're releasing bumpfee... i think we've come up with a lot of minor improvements recently and i know its a lot to keep track of..  but it doesn't make sense to me to release it for the first time with sub-optimal behavior if there are known simple fixes
393 2017-01-26T19:35:07  <morcos> gmaxwell: yeah.. maybe..   but that could be an improvement for the future... i just want to make it so the old version doesn't run into a problem where its txs aren't even accepted by peers mempools if we change default policy  (which i think should be another topic)
394 2017-01-26T19:35:43  <wumpus> well, I'm happy that at least we've merged it for 0.14, makes sense to improve it where possible before the release, if we have clear ideas of course
395 2017-01-26T19:35:56  <gmaxwell> (well the observation that a multiplictive increase is necessary and sufficient to span an arbitary range with log() bumps is not a new observation. ... I believe it's mentioned in the RBF FAQ.)
396 2017-01-26T19:36:15  <morcos> yes to be clear i'm not opposed to anyone else doing gmaxwell's idea before release.. i jsut want to do at least what i've suggested
397 2017-01-26T19:36:36  <gmaxwell> Someone should take a look at what green address and electrum are doing here to see if they've caught anything we've missed-- both have bumping in production. I volunteer to check greenaddress.
398 2017-01-26T19:36:47  <morcos> i mean this ties into my other topic
399 2017-01-26T19:37:17  <morcos> when i heard petertodd talking about how he just presses bumpfee in a loop (or maybe he does his own version, but in the future other people might just press bumpfee)
400 2017-01-26T19:37:34  <morcos> it occurred to me we are allowing WAY too much relay for 1 tx being mined
401 2017-01-26T19:38:33  <morcos> so gmaxwell is right that there are 2 ways to improve upon this... 1) raise incremental relay rate required...  and 2) make it so the behavior of our own code doesn't cause this ridiculous relay iteration by default if people want to do periodic bumping to get confirmed
402 2017-01-26T19:39:04  <gmaxwell> minrelayfee is minrealy fee, replacement is orthorgonal--  you can use X bytes of relay for exposing yourself to Y fee either way.
403 2017-01-26T19:39:06  <morcos> i don't know if it's important to do 1 or 2 before 0.14..  i don't care strongly..   but i do think they are probably both needed improvements
404 2017-01-26T19:39:33  *** instagibbs has quit IRC
405 2017-01-26T19:39:38  <BlueMatt> gmaxwell: that is no longer true (I mean it is in principal, but not in code)
406 2017-01-26T19:39:51  <BlueMatt> min relay fee is min(minRelayFee, minReplacementFee)
407 2017-01-26T19:40:22  *** instagibbs has joined #bitcoin-core-dev
408 2017-01-26T19:40:31  <gmaxwell> the fact that my mempool is sitting at 14MB of data right now suggest the relay fee is not too low, though I wish it were.
409 2017-01-26T19:40:49  <morcos> that's only b/c of good behavior
410 2017-01-26T19:41:00  <gmaxwell> uh what? the whole security design of RBF is based on the replacement being the actual in-use min-relay fee.
411 2017-01-26T19:41:45  <BlueMatt> gmaxwell: ok, hold on...there is still a min relay fee which is used for bumping, that didnt go away, its just a different CLI flag name now
412 2017-01-26T19:41:45  <morcos> so gmaxwell the new design is that incrementalrelayfee is the number that you feel like should be the minimum cost to relay
413 2017-01-26T19:41:56  <gmaxwell> morcos: the operative question is would increasing it cut of transactions that would otherwise confirm in a not crazy amount of time. And it would, I think?
414 2017-01-26T19:42:01  <morcos> definitely every byte transmitted one way or the other would have to pay at least that
415 2017-01-26T19:42:19  <morcos> minrelaytxfee in initparamaterinteraction has to be at least that.. but could optionally be higher
416 2017-01-26T19:43:26  <morcos> but my point is that number is actually really really low if you compare it to the "useful" relay rate which is much closer to 50 sat/ byte  (as opposed to 1)     and allowing somoene to relay 50 times just to keep bumping from 1 to 50, kind of sucks
417 2017-01-26T19:44:43  <gmaxwell> I don't see why you're talking about bumping.
418 2017-01-26T19:44:45  <morcos> gmaxwell: i mean i guess if we raised it from 1 to 5, then yes some small amount of txs that paid between 2-5 would have to now pay 5...   but raising it to 2 would basically harm nothing  and cut down on the potential to relay lots and lots of times for fun
419 2017-01-26T19:44:48  *** instagibbs_ has joined #bitcoin-core-dev
420 2017-01-26T19:45:35  <gmaxwell> They can also relay 50 transactions, the bumping is orthorgonal.  I would say 50 that probably won't confirm, even avoiding the fee, but thats not actually true.  (or if it's true and I didn't notice, then yes sure we should up the increment)
421 2017-01-26T19:45:42  *** Giszmo has joined #bitcoin-core-dev
422 2017-01-26T19:46:07  <gmaxwell> okay, I haven't measured carefully, if 2 is the realistic floor what what gets confirmed then thats what the value should be.
423 2017-01-26T19:46:28  <morcos> btwn 1-2 might not ever confirm.  my best guess is you have 1 chance in 3 ...   >2 would i agree eventually confirm
424 2017-01-26T19:46:34  *** instagibbs has quit IRC
425 2017-01-26T19:46:51  <gmaxwell> sounds like at a very minimum we should make an estimate now of what will realistically confirm and make the wallet do that.
426 2017-01-26T19:47:40  <morcos> anyway this is the next topic..  (topic: are we charging adequately for relay)  i just wanted to start a discussion about it.   i don't feel it has to be changed for 0.14.      but the fact that its even a consideration is why i want to future-proof the wallet for 0.14  (the change made in #9615)
427 2017-01-26T19:47:42  <gribble> https://github.com/bitcoin/bitcoin/issues/9615 | Wallet incremental fee by morcos · Pull Request #9615 · bitcoin/bitcoin · GitHub
428 2017-01-26T19:48:13  *** Giszmo has quit IRC
429 2017-01-26T19:48:29  <wumpus> #topic are we charging adequately for relay?
430 2017-01-26T19:48:54  <gmaxwell> morcos: we should change wallet behavior in advance of changing relay behavior.
431 2017-01-26T19:49:34  <gmaxwell> so if we think relay behavior should change to 2-3 we should change wallet to that now. these are all insignificant amounts.
432 2017-01-26T19:49:56  <morcos> i think we might be done with that topic too... i think greg's point is if someting close to the low end of relay fee can still get confirmed a non-trivial amount of the time.. then relay cost isn't too high.  i agree this seems to be true.. maybe we could raise from 1 to 2..  but it seems insufficiently motivated to push through now
433 2017-01-26T19:50:34  <gmaxwell> 2s/b is a half cent for a median size txn at $1000/btc.
434 2017-01-26T19:50:34  <morcos> gmaxwell: yes...  wallet change in 9615 is to pay at least 5 greater than transaction it is replacing... small enough not to hurt but enough to be in advance of future changes
435 2017-01-26T19:52:02  * BlueMatt got 0.1 s/b confirmed last weekend pretty easily, so I think it is premature to be discussing bumping it
436 2017-01-26T19:52:12  <BlueMatt> (not proposing we lower it, but blocks are very often not full at all)
437 2017-01-26T19:52:17  <gmaxwell> as far as what gets confirmed, I think we have hangover legacy of many miners having turned up minrelay fee before there was mempool limiting and before createnewblock was fast.
438 2017-01-26T19:54:29  <gmaxwell> So it may be prudent to first rename the arguments to cause people to reconsider or go back to the defaults... before concluding that 1s/b will not confirm. doubly so with the fact that segwit may well put the fee behavior back in a disfunctional state (though perhaps thats also an argument to increase the default minimum relay fee in advance of it.)
439 2017-01-26T19:54:57  *** emzy has quit IRC
440 2017-01-26T19:55:15  <instagibbs_> 5 minutes
441 2017-01-26T19:55:47  <BlueMatt> gmaxwell: thats fair
442 2017-01-26T19:55:55  <BlueMatt> I'm not against renaming the relay fee options
443 2017-01-26T19:56:23  *** emzy has joined #bitcoin-core-dev
444 2017-01-26T19:56:31  <morcos> There is basically no reason to use minrelaytxfee at all anymore...
445 2017-01-26T19:56:44  <morcos> in fact in my remove priority PR i make it so you can set it to 0
446 2017-01-26T19:57:04  <wumpus> no conceptual problems with ti, but it's too late to make option changes for 0.14
447 2017-01-26T19:57:16  <morcos> but incrementalrelayfee controls cost of relay and blockmintxfee controls orphan risk
448 2017-01-26T19:57:42  <morcos> so we can just advise in the 0.14 release notes that it is not a necessary DoS protection to set minrelaytxfee at all any more
449 2017-01-26T19:57:50  <gmaxwell> I doubt its much correlated with orphan risk at all now due to Fibre and BIP152.
450 2017-01-26T19:57:52  <morcos> (not to mention mempool limiting and the mempool min fee)
451 2017-01-26T19:57:57  <instagibbs_> People will have to intervene to turn on walletrbf, I don't think a default tweak is a bridge too far as well.
452 2017-01-26T19:58:24  <gmaxwell> Lets announce in the release notes that the option will be renamed, and encourage people to remove it.
453 2017-01-26T19:58:28  <BlueMatt> if you're using FIBRE (some pools still arent), there is 0 correlation....
454 2017-01-26T19:58:38  <wumpus> +1 gmaxwell
455 2017-01-26T19:58:44  <morcos> gmaxwell: sounds good.
456 2017-01-26T19:59:31  *** emzy has quit IRC
457 2017-01-26T19:59:31  *** emzy has joined #bitcoin-core-dev
458 2017-01-26T19:59:54  <gmaxwell> BlueMatt: not for 0.14 but someone really ought to implement the createnewblock tweak to skip very recently recieved low fee txn.. which does have a relationship to orphan risk. I think doing something fairly dumb would still be a big improvement.
459 2017-01-26T19:59:55  <wumpus> #endmeeting
460 2017-01-26T19:59:55  <lightningbot> Meeting ended Thu Jan 26 19:59:55 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
461 2017-01-26T19:59:55  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.html
462 2017-01-26T19:59:55  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.txt
463 2017-01-26T19:59:55  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-26-19.00.log.html
464 2017-01-26T20:01:11  <instagibbs_> gmaxwell: do you think this is part of the unseen transactions that CB misses from mempool?
465 2017-01-26T20:01:31  <sipa> i assume so
466 2017-01-26T20:02:22  <BlueMatt> gmaxwell: yea, i think we've talked about this before...needs to happen
467 2017-01-26T20:02:32  <gmaxwell> instagibbs_: oh absolutely, with the extra pool there should only be two remaining sources of misses--  things that just didn't propagate yet (those), and miners with 'priority service'.
468 2017-01-26T20:02:33  <morcos> gmaxwell: -blockrecenttxminfee ?
469 2017-01-26T20:02:41  <morcos> I would like a baker's dozen min fees
470 2017-01-26T20:02:52  <instagibbs_> gmaxwell: yes OOB was my other thought
471 2017-01-26T20:02:58  <instagibbs_> wasn't sure of proportion
472 2017-01-26T20:03:23  <instagibbs_> high fee not prop vs low fee not prop vs low fee + OOB
473 2017-01-26T20:03:27  <sipa> or a conversion factor between time and feerate... higher fee things may be worth taking a slight propagation risk for
474 2017-01-26T20:03:32  <gmaxwell> morcos: sounds fine to me. could be set pretty high, my perspective is that the only reason to not deny very recent txn completely is that someone may notice themselves missing a large fee and feel regret. :)
475 2017-01-26T20:04:21  <gmaxwell> I collected data for that, measuring the mempool consistency between a node in europe, califorina, and au.  Somewhere I have graphs.
476 2017-01-26T20:04:36  <instagibbs_> miners may be willing to miss out on a single reasonble fee tx, but maybe not a 150BTC one ;)
477 2017-01-26T20:04:44  <gmaxwell> instagibbs_: dunno the propotion but we can't do anything about OOB.
478 2017-01-26T20:05:26  <sdaftuar> we could prefill the compact block
479 2017-01-26T20:05:58  <gmaxwell> yea, I don't want to create an incentive to go rip out or deactivate a good feature because you missed a 1BTC fee.  anyways, I did math on a orphaning mediated rational setting and came up with some number that was significantly higher than typical fees at the time, but I think actually lower than typical fees now.
480 2017-01-26T20:06:54  <gmaxwell> sdaftuar: yes, 0.15 feature, we needed extra in first-- since the best scheme I'm aware of for prefill is to use what missed on transmission to you... it was important to get your own logic as smart as possible first.
481 2017-01-26T20:07:28  <sdaftuar> sure, makes sense
482 2017-01-26T20:07:59  <sdaftuar> these createnewblock changes are just hard to reason about without real-world data on the various tradeoffs
483 2017-01-26T20:08:56  <gmaxwell> well I collected data that IIRC basically said everyone was consistent after about 10 seconds. I don't even think never including transactions until you've had them for 10 seconds would be bad... except for the risk that it might enrage someone due to missing a high fee txn.
484 2017-01-26T20:09:52  <gmaxwell> so my thought was just having a dumb limit, ignore txn newer to you than ten seconds unless the fee rate is 'high'.  ten seconds is an insigificant enough delay to mostly not care about it.
485 2017-01-26T20:10:02  <gmaxwell> new measurements should be performned I guess.
486 2017-01-26T20:10:22  <sdaftuar> ok, maybe that is simple enough to just do then
487 2017-01-26T20:10:39  *** arubi has joined #bitcoin-core-dev
488 2017-01-26T20:10:46  *** arubi has quit IRC
489 2017-01-26T20:10:46  *** arubi has joined #bitcoin-core-dev
490 2017-01-26T20:10:57  <sdaftuar> my initial thought was, maybe we should include a small recent medium fee tx that we can prefill without eg using more packets on the wire for the compact block
491 2017-01-26T20:11:04  <sdaftuar> but taht's definitely too complicated :)
492 2017-01-26T20:11:21  <gmaxwell> yea, and who cares that you delay a typical fee by ten seconds? you'll include another typical fee instead. :)
493 2017-01-26T20:11:25  <sdaftuar> right
494 2017-01-26T20:11:33  <instagibbs_> gmaxwell: is your thought to also prefill(after complete misses) the extra pool hits if space allowed?
495 2017-01-26T20:12:14  *** arubi has quit IRC
496 2017-01-26T20:12:17  <gmaxwell> instagibbs_: no, I would propose we see how many we missed, if it's too many do no prefill. If it's not, prefill only our misses... assumption is that the peers mempool is the same as ours.
497 2017-01-26T20:12:47  <instagibbs_> you're also assuming there that extra pool is same(maybe right)
498 2017-01-26T20:12:48  <gmaxwell> if we missed too many, assumption is they're going to take a RTT regardless, don't waste bandwidth on prefill that the're going to get three copies of.
499 2017-01-26T20:13:13  <gmaxwell> instagibbs_: I am. well extra pool unlike mempool is actually convergent.. (or at least ignoring its size limit it is)
500 2017-01-26T20:13:38  <gmaxwell> e.g. given time extra pools become more similar while due to rbf-acceptance-threshold and doublespends the mempool is not.
501 2017-01-26T20:13:45  <morcos> wait, so it won't count as a miss if it was in our extrapool right
502 2017-01-26T20:13:57  <gmaxwell> Yes.
503 2017-01-26T20:13:59  <instagibbs_> correct
504 2017-01-26T20:14:30  <gmaxwell> We could expirement with things but "peer is the same as us" is a really good first approximation that will be hard to beat.
505 2017-01-26T20:15:27  <gmaxwell> it's also important to not overdo the prefill: the prefill is in the same message as the CB so any size added to the prefill adds delay to the CB even if the peer could perform a prefill-less reconstruction.
506 2017-01-26T20:15:29  <sdaftuar> huh, i hadn't thought about extrapool convergence before.  will it really converge, given that we don't relay the things in it?  or are you saying that extrapool+mempool taken together should converge?
507 2017-01-26T20:15:55  <gmaxwell> sdaftuar: extrapool+mempool will converge where mempool alone will not.
508 2017-01-26T20:16:04  <instagibbs_> sdaftuar: you relayed them in the past tho
509 2017-01-26T20:16:10  *** arubi has joined #bitcoin-core-dev
510 2017-01-26T20:16:11  <sdaftuar> instagibbs_: not orphans
511 2017-01-26T20:16:24  <gmaxwell> Subject to all sorts of messy bits of reality...
512 2017-01-26T20:16:39  <instagibbs_> sdaftuar: mm yes
513 2017-01-26T20:16:43  <gmaxwell> but once you have a conflict in your mempool you'll never accept the alternative no matter how many times it gets given to you.
514 2017-01-26T20:17:06  <instagibbs_> that's an arg to prefil orphans
515 2017-01-26T20:17:27  <gmaxwell> extrapool isn't like that. :) "Give me your tired, your poor,
516 2017-01-26T20:17:28  <gmaxwell> Your huddled masses yearning to breathe free"
517 2017-01-26T20:17:31  <instagibbs_> but maybe same peers are passing to you, *shrug*
518 2017-01-26T20:18:58  <gmaxwell> in any case before BIP152 spec was done, I tested prefill based on misses and it cut the rount trip rate by a ton... but it was on a dumb test network.  debug=mempool logs enough to let you make the measurement with existing nodes.
519 2017-01-26T20:19:06  *** buddhaghosa has joined #bitcoin-core-dev
520 2017-01-26T20:19:32  <gmaxwell> e.g. if there are IIRC <5 missing it logs the missed txids.  so you can compare that on a pair of nodes to see how many RT it would eliminate.
521 2017-01-26T20:20:46  <BlueMatt> gmaxwell: that was with an infinte extrapool, no?
522 2017-01-26T20:20:55  <BlueMatt> (well, effectively infinite by looking back through debug.log)
523 2017-01-26T20:21:46  <instagibbs_> how do you specify two debug flags, mempool and cmpctblock?
524 2017-01-26T20:21:49  <instagibbs_> btw
525 2017-01-26T20:21:55  <instagibbs_> without doing debug=1
526 2017-01-26T20:22:08  <sipa> -debug=mempool -debug=cmpctblock ?
527 2017-01-26T20:22:11  <BlueMatt> -debug=mempool -debug=cmpctblock
528 2017-01-26T20:22:15  <sipa> same as with all multiarg
529 2017-01-26T20:22:35  <BlueMatt> it is confusing that some of our args are multiarg some of them are replace-last-arg
530 2017-01-26T20:23:05  <instagibbs_> oh mapmultiArgs, yes
531 2017-01-26T20:23:15  <instagibbs_> should have tried
532 2017-01-26T20:25:05  *** jtimon has quit IRC
533 2017-01-26T20:27:34  <gmaxwell> BlueMatt: yes.
534 2017-01-26T20:37:15  *** instagibbs_ has quit IRC
535 2017-01-26T20:58:37  <bitcoin-git> [bitcoin] sdaftuar opened pull request #9640: Bumpfee: bugfixes for error handling and feerate calculation (master...2017-01-bumpfee-error-cleanup) https://github.com/bitcoin/bitcoin/pull/9640
536 2017-01-26T21:04:00  *** Kexkey has joined #bitcoin-core-dev
537 2017-01-26T21:04:12  *** Sosumi has quit IRC
538 2017-01-26T21:26:07  *** MarcoFalke has left #bitcoin-core-dev
539 2017-01-26T21:28:08  *** chjj has quit IRC
540 2017-01-26T21:38:13  *** waxwing has quit IRC
541 2017-01-26T21:57:22  *** chjj has joined #bitcoin-core-dev
542 2017-01-26T21:57:36  *** aguycalled has joined #bitcoin-core-dev
543 2017-01-26T22:06:29  *** Kexkey has quit IRC
544 2017-01-26T22:14:40  *** jtimon has joined #bitcoin-core-dev
545 2017-01-26T22:23:09  *** shesek has quit IRC
546 2017-01-26T22:29:05  *** wvr has quit IRC
547 2017-01-26T22:37:05  *** shesek has joined #bitcoin-core-dev
548 2017-01-26T22:54:06  *** ptk has joined #bitcoin-core-dev
549 2017-01-26T22:54:41  <ptk> hi
550 2017-01-26T22:55:41  <ptk> can you help me?
551 2017-01-26T22:55:51  <ptk> # Build the library and install to our prefix cd db-4.8.30.NC/build_unix/ #  Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime ../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX make install
552 2017-01-26T22:55:58  <ptk> This don't work
553 2017-01-26T22:56:14  <ptk> Ask me for the doc
554 2017-01-26T23:02:32  <ptk> #join inversores
555 2017-01-26T23:02:36  *** ptk has left #bitcoin-core-dev
556 2017-01-26T23:30:56  *** justanotheruser has joined #bitcoin-core-dev
557 2017-01-26T23:34:32  <jtimon> mhmm, reading https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.14.0-Release-notes#opt-into-full-rbf-when-sending
558 2017-01-26T23:34:51  <jtimon> I thought full RBF was the original version without opt-in or anything
559 2017-01-26T23:35:05  *** waxwing has joined #bitcoin-core-dev
560 2017-01-26T23:42:23  <luke-jr> indeed, that should be rephrased
561 2017-01-26T23:45:12  <sipa> jtimon, luke-jr: agree it may be confusing, but that's the name that has always been used (see BIP 125, even)
562 2017-01-26T23:45:45  <luke-jr> sipa: is it any worse if we leave off "full"?
563 2017-01-26T23:46:30  <sipa> it's full RBF as opposed to condition RBF (which is only replacing things when all outputs are maintained)
564 2017-01-26T23:46:30  <jtimon> oh, I see
565 2017-01-26T23:46:30  <sipa> luke-jr: i think we can drop the 'full', yes
566 2017-01-26T23:46:30  <sipa> just pointing out the history behind it
567 2017-01-26T23:47:35  <jtimon> yeah, thanks, and ack on dropping the full, it may confuse someone else and it reads well without it
568 2017-01-26T23:50:06  <gmaxwell> need to stop saying RBF and just start saying BIP125 replacable. So much more clear. :P
569 2017-01-26T23:51:56  <jtimon> right