1 2017-03-16T00:02:05  *** sanada has joined #bitcoin-core-dev
  2 2017-03-16T00:05:48  *** chris200_ has quit IRC
  3 2017-03-16T00:11:03  *** goksinen has joined #bitcoin-core-dev
  4 2017-03-16T00:11:39  *** chris2000 has joined #bitcoin-core-dev
  5 2017-03-16T00:15:27  *** goksinen has quit IRC
  6 2017-03-16T00:26:12  *** dcousens has joined #bitcoin-core-dev
  7 2017-03-16T00:27:09  <dcousens> I know ZMQ doesn't guarantee your message,  but I'm currently getting a ~1/3 miss rate for hashblock messages,  could hashtx messages just be flooding it too much?
  8 2017-03-16T00:29:55  * gmaxwell #include <generic_whining_about_zmq.h>
  9 2017-03-16T00:30:16  <gmaxwell> dcousens: you could try commenting that out and see if it solves it?
 10 2017-03-16T00:33:39  <dcousens> gmaxwell: ? would you rather I make an issue? Its a genuine question
 11 2017-03-16T00:42:56  *** goksinen has joined #bitcoin-core-dev
 12 2017-03-16T00:47:05  *** goksinen has quit IRC
 13 2017-03-16T00:47:45  <gmaxwell> I don't have anything useful to suggest other than from my totally ignorant perspective the idea that the flood of tx is contributing to loss sounds plausable to me.
 14 2017-03-16T00:55:23  <jcorgan> dcousens: there could be a number of issues causing that.  for one, zmq PUB ports are designed to drop msgs to slow listeners, but i don't recall offhand what the boundary conditions are
 15 2017-03-16T00:55:55  <jcorgan> if you can document it in more detail as an issue, i can take a look at it
 16 2017-03-16T00:58:44  *** goksinen has joined #bitcoin-core-dev
 17 2017-03-16T01:00:02  *** instagibbs has joined #bitcoin-core-dev
 18 2017-03-16T01:00:26  *** echonaut has quit IRC
 19 2017-03-16T01:01:15  *** echonaut has joined #bitcoin-core-dev
 20 2017-03-16T01:02:38  <dcousens> jcorgan: it appears no ZMQ sequence numbers are being skipped - so I'm going to debug and determine if the issue lies elsewhere in bitcoind or otherwise
 21 2017-03-16T01:02:57  *** goksinen has quit IRC
 22 2017-03-16T01:07:20  *** vogelito has quit IRC
 23 2017-03-16T01:07:21  *** Chris_Stewart_5 has quit IRC
 24 2017-03-16T01:08:21  <dcousens> jcorgan: nevermind,  it appears when a new block comes in with transactions unseen,  the spam causes mass message loss including the hashblock itself
 25 2017-03-16T01:08:35  <dcousens> I get 2-3000 sequence number differences
 26 2017-03-16T01:08:40  <jcorgan> eww
 27 2017-03-16T01:09:03  <jcorgan> you can separate those onto two different ports
 28 2017-03-16T01:11:05  *** PaulCapestany has quit IRC
 29 2017-03-16T01:12:50  <dcousens> jcorgan: will check that out,  but cheers for help :)
 30 2017-03-16T01:14:36  *** PaulCapestany has joined #bitcoin-core-dev
 31 2017-03-16T01:17:47  *** vogelito has joined #bitcoin-core-dev
 32 2017-03-16T01:20:58  *** PRab has joined #bitcoin-core-dev
 33 2017-03-16T01:22:57  *** goksinen has joined #bitcoin-core-dev
 34 2017-03-16T01:23:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 35 2017-03-16T01:25:29  *** vogelito has quit IRC
 36 2017-03-16T01:27:21  *** goksinen has quit IRC
 37 2017-03-16T01:28:52  *** vogelito has joined #bitcoin-core-dev
 38 2017-03-16T01:33:50  *** vogelito has quit IRC
 39 2017-03-16T01:36:09  *** goksinen has joined #bitcoin-core-dev
 40 2017-03-16T01:43:28  <bitcoin-git> [bitcoin] sdaftuar opened pull request #10006: [0.14 backport] Don't require segwit in getblocktemplate for segwit signalling or mining (0.14...backport-9955) https://github.com/bitcoin/bitcoin/pull/10006
 41 2017-03-16T01:44:05  *** Ylbam has quit IRC
 42 2017-03-16T01:45:00  *** PRab has quit IRC
 43 2017-03-16T01:46:34  *** Chris_Stewart_5 has quit IRC
 44 2017-03-16T01:54:47  *** vogelito has joined #bitcoin-core-dev
 45 2017-03-16T02:15:01  *** vogelito has quit IRC
 46 2017-03-16T02:15:14  *** goksinen has quit IRC
 47 2017-03-16T02:16:33  *** vogelito has joined #bitcoin-core-dev
 48 2017-03-16T02:20:45  *** vogelito has quit IRC
 49 2017-03-16T02:41:19  *** testee has joined #bitcoin-core-dev
 50 2017-03-16T02:41:32  *** testee has quit IRC
 51 2017-03-16T02:44:20  *** vogelito has joined #bitcoin-core-dev
 52 2017-03-16T02:45:50  *** goksinen has joined #bitcoin-core-dev
 53 2017-03-16T02:50:27  *** goksinen has quit IRC
 54 2017-03-16T02:57:34  *** vogelito has quit IRC
 55 2017-03-16T02:58:09  *** vogelito has joined #bitcoin-core-dev
 56 2017-03-16T02:58:24  *** dodomojo has joined #bitcoin-core-dev
 57 2017-03-16T03:18:12  *** goksinen has joined #bitcoin-core-dev
 58 2017-03-16T03:22:27  *** goksinen has quit IRC
 59 2017-03-16T03:32:45  *** vogelito has quit IRC
 60 2017-03-16T03:42:47  *** CubicEarth has joined #bitcoin-core-dev
 61 2017-03-16T03:45:38  *** dodomojo has quit IRC
 62 2017-03-16T03:47:54  *** vogelito has joined #bitcoin-core-dev
 63 2017-03-16T03:48:58  *** goksinen has joined #bitcoin-core-dev
 64 2017-03-16T03:53:32  *** goksinen has quit IRC
 65 2017-03-16T04:03:37  *** vogelito has quit IRC
 66 2017-03-16T04:06:17  *** vogelito has joined #bitcoin-core-dev
 67 2017-03-16T04:10:28  *** randy-waterhouse has joined #bitcoin-core-dev
 68 2017-03-16T04:10:57  *** randy-waterhouse has joined #bitcoin-core-dev
 69 2017-03-16T04:14:03  *** chris200_ has joined #bitcoin-core-dev
 70 2017-03-16T04:16:16  *** chris2000 has quit IRC
 71 2017-03-16T04:21:08  *** goksinen has joined #bitcoin-core-dev
 72 2017-03-16T04:25:27  *** goksinen has quit IRC
 73 2017-03-16T04:30:08  *** Giszmo has quit IRC
 74 2017-03-16T04:50:46  *** kkode has quit IRC
 75 2017-03-16T04:53:12  *** goksinen has joined #bitcoin-core-dev
 76 2017-03-16T04:53:16  *** AaronvanW has quit IRC
 77 2017-03-16T04:53:28  *** btcdrak has quit IRC
 78 2017-03-16T04:54:48  *** btcdrak has joined #bitcoin-core-dev
 79 2017-03-16T04:57:27  *** goksinen has quit IRC
 80 2017-03-16T05:14:45  *** wasi has quit IRC
 81 2017-03-16T05:15:08  *** wasi has joined #bitcoin-core-dev
 82 2017-03-16T05:24:06  *** goksinen has joined #bitcoin-core-dev
 83 2017-03-16T05:28:27  *** goksinen has quit IRC
 84 2017-03-16T06:01:50  *** moli_ has quit IRC
 85 2017-03-16T06:12:25  *** [Author] has quit IRC
 86 2017-03-16T06:18:28  *** Aaronvan_ has joined #bitcoin-core-dev
 87 2017-03-16T06:20:32  *** [Author] has joined #bitcoin-core-dev
 88 2017-03-16T06:24:32  *** Aaronvan_ has quit IRC
 89 2017-03-16T06:28:12  *** AaronvanW has joined #bitcoin-core-dev
 90 2017-03-16T06:31:45  <gmaxwell> what time is the meeting? my calandar shows unmoved but the US recently went through DST so I think my calandar is wrong.
 91 2017-03-16T06:32:24  <gmaxwell> though tne entry is set to iceland time.
 92 2017-03-16T06:32:47  *** AaronvanW has quit IRC
 93 2017-03-16T06:33:48  *** aalex has joined #bitcoin-core-dev
 94 2017-03-16T06:36:35  <achow101> gmaxwell: the meeting is 1 hour after whatever the meeting time was for you last week
 95 2017-03-16T06:37:10  <gmaxwell> what is the scheduled time?
 96 2017-03-16T06:37:30  <achow101> 7 pm utc
 97 2017-03-16T06:37:51  <gmaxwell> ok good.
 98 2017-03-16T06:40:07  *** aalex has quit IRC
 99 2017-03-16T06:44:20  *** jtimon has quit IRC
100 2017-03-16T06:49:22  *** AaronvanW has joined #bitcoin-core-dev
101 2017-03-16T06:54:08  *** AaronvanW has quit IRC
102 2017-03-16T06:57:48  *** CubicEarth has quit IRC
103 2017-03-16T07:03:26  *** Ylbam has joined #bitcoin-core-dev
104 2017-03-16T07:04:50  *** kexkey has quit IRC
105 2017-03-16T07:06:33  *** vogelito has quit IRC
106 2017-03-16T07:13:47  <Lightsword> what do I have to do to mine directly to a witness address on testnet? I tried setting it to 2NF1bac2Q8CJem1sy95pcZ82kfaMaPBuRhm but the generation transaction address in the block was n3HKtNgumrvBFB2c4RWXLTttAhTPxWPSQo
107 2017-03-16T07:21:45  *** RoyceX has quit IRC
108 2017-03-16T07:28:51  <bitcoin-git> [bitcoin] NicolasDorier opened pull request #10007: [QT] Remove SendToSelf, and break down its payouts (master...watchonlylabel2) https://github.com/bitcoin/bitcoin/pull/10007
109 2017-03-16T07:45:20  *** BashCo has quit IRC
110 2017-03-16T07:50:38  *** AaronvanW has joined #bitcoin-core-dev
111 2017-03-16T07:55:34  *** AaronvanW has quit IRC
112 2017-03-16T08:03:39  *** AaronvanW has joined #bitcoin-core-dev
113 2017-03-16T08:07:36  *** BashCo has joined #bitcoin-core-dev
114 2017-03-16T08:08:12  <bitcoin-git> [bitcoin] practicalswift opened pull request #10008: [trivial] Fix a typo (introduced two days ago) in the default fee warning (master...fix-typo-in-default-fee-warning) https://github.com/bitcoin/bitcoin/pull/10008
115 2017-03-16T08:08:20  *** AaronvanW has quit IRC
116 2017-03-16T08:11:49  <bitcoin-git> [bitcoin] tjps opened pull request #10009: [trivial] Fixing -Wshadow warnings (master...tjps_shadowing) https://github.com/bitcoin/bitcoin/pull/10009
117 2017-03-16T08:20:53  *** AaronvanW has joined #bitcoin-core-dev
118 2017-03-16T08:25:08  *** AaronvanW has quit IRC
119 2017-03-16T08:25:25  <sipa> Lightsword: testnet uses different address prefixes, including for p2sh
120 2017-03-16T08:29:27  *** voyager_ has quit IRC
121 2017-03-16T08:29:42  *** voyager_ has joined #bitcoin-core-dev
122 2017-03-16T08:34:18  <sipa> Lightsword: addwitnessaddress should work, though, on a testnet node
123 2017-03-16T08:34:29  <Lightsword> sipa, oh well guess this is why https://bitbucket.org/ckolivas/ckpool/src/6700c0fae04e2d0fa347dfacd98acf15bd297f51/src/stratifier.c?at=master&fileviewer=file-view-default#stratifier.c-8540:8543 what are all the testnet prefixs or the correct way to do that?
124 2017-03-16T08:35:06  <Lightsword> I’m pretty sure that comment is incorrect
125 2017-03-16T08:35:14  <Lightsword> since ckpool can generate to mainnet P2SH
126 2017-03-16T08:50:38  *** moli_ has joined #bitcoin-core-dev
127 2017-03-16T09:00:48  *** riemann has joined #bitcoin-core-dev
128 2017-03-16T09:18:17  *** Guyver2 has joined #bitcoin-core-dev
129 2017-03-16T09:36:30  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce01e6226ce5...d42729a8fbb6
130 2017-03-16T09:36:30  <bitcoin-git> bitcoin/master a3ca43b practicalswift: [trivial] Fix a typo (introduced two days ago) in the default fee warning
131 2017-03-16T09:36:31  <bitcoin-git> bitcoin/master d42729a Jonas Schnelli: Merge #10008: [trivial] Fix a typo (introduced two days ago) in the default fee warning...
132 2017-03-16T09:36:53  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #10008: [trivial] Fix a typo (introduced two days ago) in the default fee warning (master...fix-typo-in-default-fee-warning) https://github.com/bitcoin/bitcoin/pull/10008
133 2017-03-16T09:51:05  *** paveljanik has quit IRC
134 2017-03-16T10:03:35  *** harrymm has quit IRC
135 2017-03-16T10:09:45  *** AaronvanW has joined #bitcoin-core-dev
136 2017-03-16T10:10:02  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d42729a8fbb6...ad44438aae31
137 2017-03-16T10:10:02  <bitcoin-git> bitcoin/master 1eff6c6 Lawrence Nahum: fix gitian doc example typo
138 2017-03-16T10:10:03  <bitcoin-git> bitcoin/master ad44438 Wladimir J. van der Laan: Merge #10002: fix gitian doc example script typo...
139 2017-03-16T10:10:24  <bitcoin-git> [bitcoin] laanwj closed pull request #10002: fix gitian doc example script typo (master...gitian_typos) https://github.com/bitcoin/bitcoin/pull/10002
140 2017-03-16T10:13:52  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad44438aae31...8bcf9342b850
141 2017-03-16T10:13:52  <bitcoin-git> bitcoin/master b26ea0a Mike van Rossum: specify blockchain size & default behaviour (over pruning)
142 2017-03-16T10:13:53  <bitcoin-git> bitcoin/master 8bcf934 Wladimir J. van der Laan: Merge #9995: [doc] clarify blockchain size and pruning...
143 2017-03-16T10:14:14  <bitcoin-git> [bitcoin] laanwj closed pull request #9995: [doc] clarify blockchain size and pruning (master...update-doc-2) https://github.com/bitcoin/bitcoin/pull/9995
144 2017-03-16T10:14:46  *** AaronvanW has quit IRC
145 2017-03-16T10:19:48  *** harrymm has joined #bitcoin-core-dev
146 2017-03-16T10:22:11  <MarcoFalke> wumpus: re #9969. bitcoin-qt/gui is sometimes referred to as "wallet"
147 2017-03-16T10:22:13  <gribble> https://github.com/bitcoin/bitcoin/issues/9969 | 0.14.0 Runtime Error/Out of memory · Issue #9969 · bitcoin/bitcoin · GitHub
148 2017-03-16T10:22:36  <MarcoFalke> I don't think they meant the wallet specifically
149 2017-03-16T10:24:44  <wumpus> ah, okay
150 2017-03-16T10:28:47  *** AaronvanW has joined #bitcoin-core-dev
151 2017-03-16T10:31:53  *** aalex has joined #bitcoin-core-dev
152 2017-03-16T10:35:46  *** Gerardo2 has quit IRC
153 2017-03-16T10:35:55  <luke-jr> NicolasDorier: is your PR description outdated then? O.o
154 2017-03-16T10:36:02  <NicolasDorier> no
155 2017-03-16T10:36:02  *** Dax2 has joined #bitcoin-core-dev
156 2017-03-16T10:36:09  <NicolasDorier> what I do is
157 2017-03-16T10:36:12  <NicolasDorier> in the case where
158 2017-03-16T10:36:19  <NicolasDorier> All input and all output are from me
159 2017-03-16T10:36:38  <NicolasDorier> show 1 lines for the debit. Which Label is taken from the first input
160 2017-03-16T10:36:40  <luke-jr> each output should get one "send" and one "receive" with the same label based on the output address
161 2017-03-16T10:36:48  <luke-jr> inputs don't have labels
162 2017-03-16T10:37:29  <NicolasDorier> I take the ScriptPubKey of the first input and use that as the label for the debit
163 2017-03-16T10:37:37  <NicolasDorier> then 1 line per output
164 2017-03-16T10:38:08  *** aalex has quit IRC
165 2017-03-16T10:38:37  <luke-jr> NicolasDorier: don't do that.
166 2017-03-16T10:38:45  <NicolasDorier> the idea is that when you read the transaction log, you can follow where the coin leave and where it go. This is very useful for every 2nd layer protocols because bitcoin core can show that is happening
167 2017-03-16T10:38:58  <NicolasDorier> ok so let's take an example with Lightning
168 2017-03-16T10:39:15  <NicolasDorier> Imagine that you fund a channel
169 2017-03-16T10:39:25  <NicolasDorier> then later you close the channel
170 2017-03-16T10:39:46  <NicolasDorier> what you want to see in the log is
171 2017-03-16T10:39:48  <luke-jr> the GUI isn't 2nd layers or Lightning.
172 2017-03-16T10:40:40  <NicolasDorier> (na) [+1.0]
173 2017-03-16T10:40:40  <NicolasDorier> Channel [-1.0]
174 2017-03-16T10:40:40  <NicolasDorier> Channel [+1.0]
175 2017-03-16T10:40:40  <NicolasDorier> (na) [-1.0]
176 2017-03-16T10:40:49  <NicolasDorier> oops
177 2017-03-16T10:40:51  <NicolasDorier> I mean
178 2017-03-16T10:40:57  <NicolasDorier> no that is correct sorry
179 2017-03-16T10:41:18  <NicolasDorier> SendToSelf are only relevant for above layer protocols
180 2017-03-16T10:41:22  *** Dax2 has quit IRC
181 2017-03-16T10:41:37  <NicolasDorier> and this is a way to make the SendToSelf actually usefull to anything
182 2017-03-16T10:41:43  <NicolasDorier> on the UI
183 2017-03-16T10:42:38  <luke-jr> wallets used to watch L2 stuff simply shouldn't be used directly by end users
184 2017-03-16T10:43:21  <NicolasDorier> this is what joinmarket is doing
185 2017-03-16T10:43:33  <NicolasDorier> and there is good reason imho
186 2017-03-16T10:43:34  <wumpus> well we can try to accomodate for it, but not if it breaks other valid use cases
187 2017-03-16T10:43:40  <NicolasDorier> coin tracking is hard.
188 2017-03-16T10:43:42  <NicolasDorier> coin selection is hard
189 2017-03-16T10:43:51  <NicolasDorier> I do not want to code this stuff myself
190 2017-03-16T10:43:58  <NicolasDorier> I will mess it up
191 2017-03-16T10:44:32  <wumpus> I think we should try to help projects like joinmarket and lightning where possible
192 2017-03-16T10:45:25  <NicolasDorier> I am trying to use SendToSelf which is not relevant to other valid use case than upper layer stuff (https://github.com/bitcoin/bitcoin/pull/10007)
193 2017-03-16T10:45:36  <wumpus> if a simple change in how pay to self entries are shown is useful, well , I don't see why not. Normally they don't appear anyway.
194 2017-03-16T10:46:21  <luke-jr> coin tracking is not something the GUI should try to do
195 2017-03-16T10:46:32  <luke-jr> wumpus: it's a complete layer violation
196 2017-03-16T10:46:34  <NicolasDorier> shit power is running out. Will try to be there for dev meeting today to talk about it. (it is at 4am in japan so kind of hard)
197 2017-03-16T10:46:40  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bcf9342b850...c49355c7170a
198 2017-03-16T10:46:41  <bitcoin-git> bitcoin/master fb6f90a Patrick Strateman: Initialize nRelockTime
199 2017-03-16T10:46:41  <bitcoin-git> bitcoin/master c49355c MarcoFalke: Merge #9993: Initialize nRelockTime...
200 2017-03-16T10:46:43  <luke-jr> it's "from address" nonsense all over again
201 2017-03-16T10:46:53  <NicolasDorier> luke-jr: I do not see "from address"
202 2017-03-16T10:47:00  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9993: Initialize nRelockTime (master...2017-03-14-cwallet-nrelocktime-init) https://github.com/bitcoin/bitcoin/pull/9993
203 2017-03-16T10:47:06  <luke-jr> NicolasDorier: it's exactly what you're describing doing
204 2017-03-16T10:47:14  <NicolasDorier> I do not show from addresses
205 2017-03-16T10:47:20  <NicolasDorier> I show labels in transactions windows
206 2017-03-16T10:47:27  <luke-jr> labels are associated with addresses
207 2017-03-16T10:47:46  <NicolasDorier> shit no power, come back a bit later
208 2017-03-16T10:47:51  *** randy-waterhouse has quit IRC
209 2017-03-16T10:48:58  <MarcoFalke> ryanofsky: Mind to rebase #9701 in the next couple of days?
210 2017-03-16T10:49:00  <gribble> https://github.com/bitcoin/bitcoin/issues/9701 | Make bumpfee tests less fragile by ryanofsky · Pull Request #9701 · bitcoin/bitcoin · GitHub
211 2017-03-16T10:49:59  <wumpus> what is the goal? if the goal is isolation between different 'pools' of coins then I agree labels are not the right way to go
212 2017-03-16T10:50:19  <wumpus> that's what multiwallet would be for
213 2017-03-16T10:50:39  <wumpus> which I indended to work on this week but shit happened
214 2017-03-16T10:59:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c49355c7170a...598ef9c44b3e
215 2017-03-16T10:59:23  <bitcoin-git> bitcoin/master c9bd0f6 John Newbery: Fix RPC failure testing (2 of 2)...
216 2017-03-16T10:59:24  <bitcoin-git> bitcoin/master 598ef9c MarcoFalke: Merge #9842: Fix RPC failure testing (continuation of #9707)...
217 2017-03-16T10:59:34  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9842: Fix RPC failure testing (continuation of #9707) (master...rpctestassert2) https://github.com/bitcoin/bitcoin/pull/9842
218 2017-03-16T11:03:23  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/598ef9c44b3e...8b789d814199
219 2017-03-16T11:03:24  <bitcoin-git> bitcoin/master c459d50 Wladimir J. van der Laan: build: Probe MSG_DONTWAIT in the same way as MSG_NOSIGNAL...
220 2017-03-16T11:03:24  <bitcoin-git> bitcoin/master 25da1ee Wladimir J. van der Laan: build: cleanup: define MSG_DONTWAIT/MSG_NO_SIGNAL locally...
221 2017-03-16T11:03:25  <bitcoin-git> bitcoin/master a4d1c9f Wladimir J. van der Laan: compat: use `unsigned int` instead of `u_int`...
222 2017-03-16T11:03:43  <bitcoin-git> [bitcoin] laanwj closed pull request #9921: build: Probe MSG_DONTWAIT in the same way as MSG_NOSIGNAL (master...2017_03_cloudabi_netcompat) https://github.com/bitcoin/bitcoin/pull/9921
223 2017-03-16T11:03:47  <luke-jr> wumpus: I guess his goal is to display L2 semantics in the GUI without the GUI knowing L2 stuff. Not sure.
224 2017-03-16T11:16:25  <MarcoFalke> maybe a good time to clear the release notes on the 0.14 branch
225 2017-03-16T11:17:09  <NicolasDorier> wumpus: The goal is to make it possible to follow the coins from L2 transfers from the Bitcoin qt interface
226 2017-03-16T11:17:13  <NicolasDorier> for lightning
227 2017-03-16T11:17:17  <NicolasDorier> for example
228 2017-03-16T11:17:26  <NicolasDorier> if the channel get open then closed
229 2017-03-16T11:17:28  <NicolasDorier> you would like to see
230 2017-03-16T11:17:37  <wumpus> NicolasDorier: aren't we missing the metadata for that?
231 2017-03-16T11:17:49  <wumpus> MarcoFalke: yes, good idea
232 2017-03-16T11:17:52  <NicolasDorier> "Channel X" +1 BTC
233 2017-03-16T11:17:53  <NicolasDorier> "Channel X" -1 BTC
234 2017-03-16T11:18:12  <NicolasDorier> labels being submitted by the Layer 2 process
235 2017-03-16T11:18:24  <wumpus> ok, sounds fair enough to me
236 2017-03-16T11:18:49  <NicolasDorier> in the PR I gave an example with tumble bit where the coins flow internally through 3 different transactions
237 2017-03-16T11:19:14  <NicolasDorier> and I would like users to see something like
238 2017-03-16T11:19:17  <NicolasDorier> Tumbler  [1.0]
239 2017-03-16T11:19:17  <NicolasDorier> Offer       [-1.0]
240 2017-03-16T11:19:17  <NicolasDorier> Offer       [1.0]
241 2017-03-16T11:19:17  <NicolasDorier> Escrow    [-1.0]
242 2017-03-16T11:19:17  <NicolasDorier> Escrow    [1.0]
243 2017-03-16T11:19:17  <NicolasDorier> (n/a)        [-1.0]
244 2017-03-16T11:19:36  <NicolasDorier> so you can see your money go to the escrow, to the offer, then ultimately to the tumbler
245 2017-03-16T11:20:33  <wumpus> I guess tumbler, offer and escrow are separate pools of coins which shouldn't mix? how is this enforced?
246 2017-03-16T11:20:44  <NicolasDorier> not pools of coins
247 2017-03-16T11:20:45  <wumpus> when they're all in one wallet
248 2017-03-16T11:20:59  <NicolasDorier> there is no pool of coins that should not mix
249 2017-03-16T11:21:12  <wumpus> what if the user does a spend from bitcoin core?
250 2017-03-16T11:21:48  <NicolasDorier> he can. The way tumbler bit work now is to drain the bitcoin core wallet until empty to the tumbler
251 2017-03-16T11:21:57  <wumpus> the coin selection algorithm can pick from all of those utxos, despite being allocated to something (as "send to self") by L2 software
252 2017-03-16T11:22:00  <NicolasDorier> for coin separation I want the multi wallet
253 2017-03-16T11:22:07  <wumpus> right.
254 2017-03-16T11:22:24  <NicolasDorier> but right now yes, the user share the same pool of coins
255 2017-03-16T11:22:48  <NicolasDorier> the idea is that he receive money to the bitcoin core and tumblebit passively send it through the tumbler
256 2017-03-16T11:23:03  *** harrymm has quit IRC
257 2017-03-16T11:23:09  <NicolasDorier> if he does not want all the coins drained then he need separate wallet
258 2017-03-16T11:23:38  <NicolasDorier> But basically I am labelling the escrow, offer, and tumbler addresses. So that the user can see that the money does not get lost
259 2017-03-16T11:25:01  <wumpus> yes it makes sense to have some way of displaying that in the wallet GUI
260 2017-03-16T11:25:23  <wumpus> doesn't it need more metadata than just send-to-self though?
261 2017-03-16T11:26:30  <wumpus> I guess it needs some way to mark transactions, for example through RPC?
262 2017-03-16T11:27:12  <NicolasDorier> you do not mark transactions
263 2017-03-16T11:27:15  <NicolasDorier> you mark addresses
264 2017-03-16T11:27:36  <NicolasDorier> wumpus: the layer 2 instruct which address to watchonly
265 2017-03-16T11:27:40  <NicolasDorier> with their label
266 2017-03-16T11:28:04  <NicolasDorier> despite the UI show label as one per transaction, in reality it is one per addresse
267 2017-03-16T11:28:07  <wumpus> ok, metadata for the address then
268 2017-03-16T11:28:27  <NicolasDorier> on my side I do not need more metadata to show correctly
269 2017-03-16T11:28:44  <NicolasDorier> the PR I have done show quite well the flow of money through the different stages
270 2017-03-16T11:28:54  <wumpus> but it may interfere with other uses of send-to-self which should not be shown like this
271 2017-03-16T11:29:57  <NicolasDorier> a proposition that luke-jr would be fine with I think is if I do not add one entry for debits so instead of
272 2017-03-16T11:30:06  <NicolasDorier> Tumbler  [1.0]
273 2017-03-16T11:30:06  <NicolasDorier> 8:19 PM Offer       [-1.0]
274 2017-03-16T11:30:06  <NicolasDorier> 8:19 PM Offer       [1.0]
275 2017-03-16T11:30:06  <NicolasDorier> 8:19 PM Escrow    [-1.0]
276 2017-03-16T11:30:06  <NicolasDorier> 8:19 PM Escrow    [1.0]
277 2017-03-16T11:30:07  <NicolasDorier> 8:19 PM (n/a)        [-1.0]
278 2017-03-16T11:30:09  <NicolasDorier> it would be
279 2017-03-16T11:30:18  <wumpus> in that case you'd need some special flag in the address metadata, instead of treating all of them the same
280 2017-03-16T11:30:20  <wumpus> okay
281 2017-03-16T11:30:28  <NicolasDorier> Tumbler  [1.0]
282 2017-03-16T11:30:29  <NicolasDorier> 8:19 PM Offer       [1.0]
283 2017-03-16T11:30:29  <NicolasDorier> 8:19 PM Escrow    [1.0]
284 2017-03-16T11:30:47  <NicolasDorier> but I think it is not very clear
285 2017-03-16T11:30:57  <NicolasDorier> but indeed
286 2017-03-16T11:31:13  <NicolasDorier> for the debit entries, I just use the address of the first input
287 2017-03-16T11:31:24  <NicolasDorier> which might not work for all cases
288 2017-03-16T11:31:50  <luke-jr> NicolasDorier: the send+receive should always use the same label, with the current wallet structure
289 2017-03-16T11:32:32  <NicolasDorier> not sure what you nmean here
290 2017-03-16T11:32:33  <wumpus> luke-jr: but if it is *to self* that's kind of hard to define
291 2017-03-16T11:32:57  <luke-jr> wumpus: if the goal is to eliminate "send to self", it leaves just a send and a receive both with the same address
292 2017-03-16T11:34:16  <NicolasDorier> luke-jr: so how would you show ?
293 2017-03-16T11:34:39  <NicolasDorier> coming back soon
294 2017-03-16T11:34:59  <luke-jr> NicolasDorier: for each output, 1 send, and 1 receive, both with the same label/address
295 2017-03-16T11:42:47  *** harrymm has joined #bitcoin-core-dev
296 2017-03-16T11:47:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
297 2017-03-16T11:52:00  *** Chris_Stewart_5 has quit IRC
298 2017-03-16T11:55:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
299 2017-03-16T12:04:24  <NicolasDorier> luke-jr: I think it is ugly and does not really help user to understand where his money go
300 2017-03-16T12:20:02  *** d9b4bef9 has quit IRC
301 2017-03-16T12:21:09  *** d9b4bef9 has joined #bitcoin-core-dev
302 2017-03-16T12:40:21  *** CubicEarth has joined #bitcoin-core-dev
303 2017-03-16T12:54:23  *** mol has joined #bitcoin-core-dev
304 2017-03-16T12:54:24  *** moli_ has quit IRC
305 2017-03-16T13:00:30  *** CubicEarth has quit IRC
306 2017-03-16T13:00:34  *** temp has joined #bitcoin-core-dev
307 2017-03-16T13:09:15  *** laurentmt has joined #bitcoin-core-dev
308 2017-03-16T13:11:35  *** laurentmt has quit IRC
309 2017-03-16T13:11:44  *** temp has left #bitcoin-core-dev
310 2017-03-16T13:37:59  *** CubicEarth has joined #bitcoin-core-dev
311 2017-03-16T13:41:37  *** herzmeister[m] has joined #bitcoin-core-dev
312 2017-03-16T14:07:45  *** laurentmt has joined #bitcoin-core-dev
313 2017-03-16T14:07:56  *** aalex has joined #bitcoin-core-dev
314 2017-03-16T14:15:33  *** CubicEarth has quit IRC
315 2017-03-16T14:33:26  *** CubicEarth has joined #bitcoin-core-dev
316 2017-03-16T14:36:55  *** Cheeseo has joined #bitcoin-core-dev
317 2017-03-16T14:48:06  <jonasschnelli> Would be great if we could merge #9294
318 2017-03-16T14:48:11  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
319 2017-03-16T14:48:19  <jonasschnelli> I think the performance can be optimized later
320 2017-03-16T14:51:16  *** CubicEarth has quit IRC
321 2017-03-16T15:19:36  *** Giszmo has joined #bitcoin-core-dev
322 2017-03-16T15:25:10  *** JackH has joined #bitcoin-core-dev
323 2017-03-16T15:29:29  *** cluelessperson has quit IRC
324 2017-03-16T15:30:20  *** cluelessperson has joined #bitcoin-core-dev
325 2017-03-16T15:32:20  *** vogelito has joined #bitcoin-core-dev
326 2017-03-16T15:43:07  *** vogelito has quit IRC
327 2017-03-16T15:45:55  *** arubi has quit IRC
328 2017-03-16T15:45:55  *** arubi has joined #bitcoin-core-dev
329 2017-03-16T15:46:47  *** Chris_Stewart_5 has quit IRC
330 2017-03-16T15:50:41  *** abpa has joined #bitcoin-core-dev
331 2017-03-16T15:58:42  *** riemann has quit IRC
332 2017-03-16T16:01:33  *** laurentmt has quit IRC
333 2017-03-16T16:05:10  *** trotski2000 has quit IRC
334 2017-03-16T16:05:11  *** trotski2000 has joined #bitcoin-core-dev
335 2017-03-16T16:05:11  *** trotski2000 has quit IRC
336 2017-03-16T16:05:11  *** trotski2000 has joined #bitcoin-core-dev
337 2017-03-16T16:24:40  *** Sosumi has joined #bitcoin-core-dev
338 2017-03-16T16:26:56  *** vogelito has joined #bitcoin-core-dev
339 2017-03-16T16:32:31  *** nemgun has joined #bitcoin-core-dev
340 2017-03-16T16:38:35  *** jtimon has joined #bitcoin-core-dev
341 2017-03-16T16:38:39  <bitcoin-git> [bitcoin] prusnak opened pull request #10010: util: rename variable to avoid shadowing (master...master) https://github.com/bitcoin/bitcoin/pull/10010
342 2017-03-16T16:40:22  *** voyager_ has quit IRC
343 2017-03-16T16:40:48  *** voyager_ has joined #bitcoin-core-dev
344 2017-03-16T16:41:31  *** JackH has quit IRC
345 2017-03-16T16:41:57  <bitcoin-git> [bitcoin] laanwj opened pull request #10011: build: Fix typo s/HAVE_DONTWAIT/HAVE_MSG_DONTWAIT (master...2017_03_typo_dontwait) https://github.com/bitcoin/bitcoin/pull/10011
346 2017-03-16T16:49:36  <bitcoin-git> [bitcoin] raze182 opened pull request #10012: [UI] Update splash screen (master...master) https://github.com/bitcoin/bitcoin/pull/10012
347 2017-03-16T16:50:49  <bitcoin-git> [bitcoin] laanwj closed pull request #10012: [UI] Update splash screen (master...master) https://github.com/bitcoin/bitcoin/pull/10012
348 2017-03-16T16:53:25  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10013: Fix shutdown hang with >= 8 -addnodes set (0.14 backport) (0.14...2017-03-exit-with-addnode-13) https://github.com/bitcoin/bitcoin/pull/10013
349 2017-03-16T16:55:39  *** jnewbery has joined #bitcoin-core-dev
350 2017-03-16T16:56:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
351 2017-03-16T17:01:27  *** Chris_Stewart_5 has quit IRC
352 2017-03-16T17:08:13  *** vogelito has quit IRC
353 2017-03-16T17:09:53  *** BashCo_ has joined #bitcoin-core-dev
354 2017-03-16T17:11:36  *** BashCo_ has quit IRC
355 2017-03-16T17:12:17  *** goregrin1 is now known as goregrind
356 2017-03-16T17:12:50  *** BashCo has quit IRC
357 2017-03-16T17:12:59  *** vogelito has joined #bitcoin-core-dev
358 2017-03-16T17:14:42  <cfields> wumpus: grr, sorry for missing that in review
359 2017-03-16T17:25:53  *** vogelito has quit IRC
360 2017-03-16T17:29:16  *** cluelessperson has quit IRC
361 2017-03-16T17:29:47  *** cluelessperson has joined #bitcoin-core-dev
362 2017-03-16T17:30:49  <wumpus> cfields: hah yes we should have caught that one
363 2017-03-16T17:31:52  <wumpus> bah we're swamped in Wshadow pulls, exactly what we feared has happened, about every PR is followed by one that 'fixes' its shadow warnings
364 2017-03-16T17:32:23  *** JackH has joined #bitcoin-core-dev
365 2017-03-16T17:33:23  <wumpus> until a sneaky bug gets introduced in an oversight while renaming variables
366 2017-03-16T17:35:58  *** BashCo has joined #bitcoin-core-dev
367 2017-03-16T17:37:23  <ryanofsky> probably been discussed before, but could this problem be avoided by enabling -Werror in travis?
368 2017-03-16T17:37:54  <bitcoin-git> [bitcoin] laanwj closed pull request #10009: [trivial] Fixed -Wshadow warnings (master...tjps_shadowing) https://github.com/bitcoin/bitcoin/pull/10009
369 2017-03-16T17:38:30  <wumpus> no, it can not
370 2017-03-16T17:38:45  <wumpus> the problem is that different compilers have different perceptions of shadowing
371 2017-03-16T17:39:03  <wumpus> there is always someone with a compiler that shows more shadowing warnings than you
372 2017-03-16T17:39:20  <wumpus> clang shows fairly few, gcc 5 shows more, some gcc 4.x versoins go all out crazy
373 2017-03-16T17:41:06  <ryanofsky> oh, ok. still seems like it could be useful as mitigation, but maybe there are other reasons not to do it
374 2017-03-16T17:41:48  <wumpus> the reason not to do it would be that it causes a lot of extra overhead and irritation
375 2017-03-16T17:42:09  <wumpus> you say it is useful as mitigation, but are you helping review -Wshadow pulls? making sure they don't introduce bugs?
376 2017-03-16T17:43:27  <wumpus> anything that introduces so much ancillary diff noise is a risk in itself, what if something gets renamed wrongly. It was a bad idea to enable it by default.
377 2017-03-16T17:43:44  <ryanofsky> i have not, but would be happy to review and add some acks
378 2017-03-16T17:44:00  <wumpus> we hardly have enough reviewers for the pulls that actually add features or fix serious bugs
379 2017-03-16T17:44:23  <ryanofsky> oh i agree it's a dumb warning. sorry, i don't know whatever discussion happened previously around this issue
380 2017-03-16T17:45:01  <cfields> wumpus: i agree. It seemed like something that would eventually settle down and we could stick -Werror on it, but it's turned out to be very different in practice :(. It's not worth the pain it's causing
381 2017-03-16T17:45:05  <ryanofsky> was just suggesting the travis change as a way of shifting the burden of dealing with the warning from maintainers to contributors
382 2017-03-16T17:45:56  <cfields> ryanofsky: the discussion was triggered by a bug a long time ago that this would've caught, but the signal/noise is just too bad for it to be helpful
383 2017-03-16T17:46:11  <gmaxwell> What happened to the suggestion I made of tuning -Wshadow with the arguments?
384 2017-03-16T17:46:26  <gmaxwell> not successful and restricting it to things that compilers are consistent about?
385 2017-03-16T17:47:09  <wumpus> ryanofsky: the problem is that you'd have to run it against N different compiers in travis then, which would be good in itself, but another problem is that the turnaround cycle of travis is pretty slow - so you get one bucketload of warnings, fix it, travis complains about another. But sure, it'd certainly be much better to catch them before they're merged.
386 2017-03-16T17:47:26  <cfields> gmaxwell: from what i saw, the options available end up hiding the only useful warning
387 2017-03-16T17:49:57  <cfields> ryanofsky: for context, this started the discussion: #8102
388 2017-03-16T17:49:59  <gribble> https://github.com/bitcoin/bitcoin/issues/8102 | Bugfix: use global ::fRelayTxes instead of CNode in version send by sipa · Pull Request #8102 · bitcoin/bitcoin · GitHub
389 2017-03-16T17:50:15  <cfields> oh, i started the fire :(
390 2017-03-16T17:51:07  <wumpus> cfields: we didn't know better at the time
391 2017-03-16T17:52:21  <wumpus> I mean for C it would be clearly defined. It's just with C++ and all its nested scopes and global namespace symbols that compilers start to diverge on it
392 2017-03-16T17:52:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
393 2017-03-16T17:52:56  <gmaxwell> cfields: ah, I thought one of them warned only about shadowing in the same function. Which sounded basically like the primary place where shadowing is possible in C, and still sometimes finds some bugs.
394 2017-03-16T17:53:05  <bitcoin-git> [bitcoin] starinacool opened pull request #10014: 0.14 with 2Mb block size (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10014
395 2017-03-16T17:53:14  <gmaxwell> libsecp256k1 is -Wshadow never been an issue.
396 2017-03-16T17:53:41  <bitcoin-git> [bitcoin] laanwj closed pull request #10014: 0.14 with 2Mb block size (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10014
397 2017-03-16T17:53:49  <ryanofsky> cfields, thanks for context
398 2017-03-16T17:55:36  <wumpus> secp256k1 also is smaller, and has a lot fewer dependencies, that helps with having not too much cruft in namespaces that can overlap. Though C/C++ probably makes the biggest difference.
399 2017-03-16T17:56:14  <gmaxwell> (of course, I've similarly not had problems in other C librarys... I really think it's just C vs C++ that is an issue here.)
400 2017-03-16T17:56:19  <cfields> gmaxwell: i suppose that doesn't hurt. Though, I was more interested in catching accidental global shadowing. Those are really rough to catch in review.
401 2017-03-16T17:56:38  <cfields> (ofc those are the ones that cause all the trouble here)
402 2017-03-16T17:56:42  <gmaxwell> It's still surprising to me that the C++ compilers can't be reliable in this, how the hell do they resolve the symbols if they can't find them. :P
403 2017-03-16T17:58:27  <wumpus> hehe I'm sure they can find them, it's just that they have different concepts of what is reported as a shadowing warning. May be something of a compiler vendor opinion as well, you can both blame clang for underreporting and gcc for overreporting.
404 2017-03-16T17:58:33  *** laurentmt has joined #bitcoin-core-dev
405 2017-03-16T18:02:51  <wumpus> (FYI bitcoin core master compiles without WShadow warnings with clang 4.0 pre-something apart from one in db.cpp)
406 2017-03-16T18:11:49  <gmaxwell> I also worry about this constant fix stream causing us to introduce real bugs. :(  and also undermining the utility of the warning.
407 2017-03-16T18:12:17  <cfields> jnewbery: ping
408 2017-03-16T18:12:46  <jnewbery> cfields: pong
409 2017-03-16T18:13:04  <cfields> jnewbery: got a sec to talk about the test movement?
410 2017-03-16T18:13:11  <jnewbery> sure
411 2017-03-16T18:15:04  *** vogelito has joined #bitcoin-core-dev
412 2017-03-16T18:26:12  *** Chris_Stewart_5 has quit IRC
413 2017-03-16T18:26:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
414 2017-03-16T18:30:58  *** vogelito has quit IRC
415 2017-03-16T18:42:26  *** LeMiner has quit IRC
416 2017-03-16T18:43:30  *** paveljanik has joined #bitcoin-core-dev
417 2017-03-16T18:47:03  *** vogelito has joined #bitcoin-core-dev
418 2017-03-16T19:00:49  <bitcoin-git> [bitcoin] jnewbery opened pull request #10015: Wallet should reject long chains by default (master...walletrejectlongchains) https://github.com/bitcoin/bitcoin/pull/10015
419 2017-03-16T19:01:10  <Chris_Stewart_5> meeting? Or are my time zones off?
420 2017-03-16T19:01:19  <achow101> meeting
421 2017-03-16T19:01:21  <wumpus> #meetingstart
422 2017-03-16T19:01:26  <wumpus> #startmeeting
423 2017-03-16T19:01:26  <lightningbot> Meeting started Thu Mar 16 19:01:26 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
424 2017-03-16T19:01:26  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
425 2017-03-16T19:02:02  <jnewbery> suggested topic: running rpc tests as part of `make check`
426 2017-03-16T19:02:11  <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
427 2017-03-16T19:02:28  <cfields> hi
428 2017-03-16T19:02:35  <jonasschnelli> hi
429 2017-03-16T19:02:36  <instagibbs> hello
430 2017-03-16T19:02:49  <sipa> oi
431 2017-03-16T19:02:58  <wumpus> proposed topics?
432 2017-03-16T19:03:04  <jtimon> mhmm
433 2017-03-16T19:03:11  <morcos> i haven't been reading channel last few days but was there discussion on 10015 (just above)
434 2017-03-16T19:03:19  <wumpus> #10015
435 2017-03-16T19:03:20  <gribble> https://github.com/bitcoin/bitcoin/issues/10015 | Wallet should reject long chains by default by jnewbery · Pull Request #10015 · bitcoin/bitcoin · GitHub
436 2017-03-16T19:03:21  <morcos> i felt like we discussed that ad nauseum the first time around
437 2017-03-16T19:03:30  * instagibbs wimpers
438 2017-03-16T19:03:32  <instagibbs> yes
439 2017-03-16T19:03:42  <sipa> i don't remmeber the reason for it not being default
440 2017-03-16T19:03:52  <wumpus> yes I remember we already had long discussions about that
441 2017-03-16T19:04:14  <jnewbery> #9262
442 2017-03-16T19:04:15  <instagibbs> The idea being that now that we actually rebroadcast normally, and return txid, it wasn't required in general.
443 2017-03-16T19:04:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
444 2017-03-16T19:04:30  <morcos> sipa: the reasoning is its a very reasonable use case that you'd just want the tx to go out as soon as some of its parents get confirmed..
445 2017-03-16T19:04:53  <morcos> it seems somewhat likely that it would be tricky to have anything smarter than that happen manually anyway
446 2017-03-16T19:04:54  <sipa> but the resulting behaviour seems very unexpected to users
447 2017-03-16T19:05:00  <gmaxwell> I don't see the reason for rejecting. Seems like a useless loss of functionality in most cases.
448 2017-03-16T19:05:14  <morcos> but the solution to that could be better informing them of the new behaviour
449 2017-03-16T19:05:18  <jnewbery> I can understand the use case, but user experience is terrible (hence already two issues opened by different users)
450 2017-03-16T19:05:26  <gmaxwell> What does it matter to you if your transaction 20 steps deep hasn't actually been announced yet? it will be announced when it can.
451 2017-03-16T19:05:27  <sipa> many reports of people who see their balance going down
452 2017-03-16T19:05:46  <sipa> and get scared
453 2017-03-16T19:05:49  <gmaxwell> Their balance is going down.
454 2017-03-16T19:05:56  <morcos> hmm...
455 2017-03-16T19:06:14  <sipa> gmaxwell: it is, but don't you think it's better to reject by default, so they know why it is going down?
456 2017-03-16T19:06:19  <morcos> gmaxwell: i assume he means they have a 10 BTC input, they spend 0.1 BTC and their balance goes down by 10
457 2017-03-16T19:06:33  <sipa> so they can re-enable it when they understand the effect
458 2017-03-16T19:06:42  <morcos> b/c the change isn't in mempool so it doesn't count towards balance
459 2017-03-16T19:06:49  <gmaxwell> morcos: okay now that is a bad effect, I didn't reaize it was doing that.
460 2017-03-16T19:07:01  <gmaxwell> realize*
461 2017-03-16T19:07:04  <jnewbery> see #10004 for good description of what the user sees
462 2017-03-16T19:07:06  <gribble> https://github.com/bitcoin/bitcoin/issues/10004 | After max chain of unconfirmed change transactions, last tx is missing from memory until rescan · Issue #10004 · bitcoin/bitcoin · GitHub
463 2017-03-16T19:07:16  <gmaxwell> jnewbery: or  #9752 for the alternative
464 2017-03-16T19:07:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9752 | Max unconfirmed chainlength · Issue #9752 · bitcoin/bitcoin · GitHub
465 2017-03-16T19:07:18  <morcos> i briefly recall discussing that but i agree its bad so don't know why we just left it that way.. maybe b/c its not easy to do anything smarter?
466 2017-03-16T19:07:43  <gmaxwell> The balance being goofy is an issue, but I think that should be considered a seperate issue.
467 2017-03-16T19:08:01  <gmaxwell> I agree it shouldn't be left with the balance doing inexplicable things.
468 2017-03-16T19:08:05  <sipa> gmaxwell: you think we should include txn crediting the wallet that are not in the mempool?
469 2017-03-16T19:08:18  <sipa> gmaxwell: that would bring back all malleability craziness
470 2017-03-16T19:08:30  <gmaxwell> sipa: if it's the users own output? I think so.
471 2017-03-16T19:08:45  <gmaxwell> (and it's not conflicted.)
472 2017-03-16T19:08:59  <morcos> perhaps there needs to be a new category of pending txs
473 2017-03-16T19:08:59  <sipa> the conflict can be outside of the mempool
474 2017-03-16T19:09:06  <sipa> s/mempool/wallet/
475 2017-03-16T19:09:40  <morcos> The pending balance can include both the debit and the credit
476 2017-03-16T19:10:01  <morcos> But could get complicated
477 2017-03-16T19:10:17  <jonasschnelli> I tend to like this approach.
478 2017-03-16T19:10:27  <sipa> which approach?
479 2017-03-16T19:10:36  <jonasschnelli> pending txs cat
480 2017-03-16T19:11:07  <sipa> morcos: it's very hard to not double count things in the pending balance if they're spending from malleated versions of the same transaction
481 2017-03-16T19:11:37  <gmaxwell> I am dubious that your own mempool is actually that strong a protection here.
482 2017-03-16T19:12:32  <jnewbery> my view: simplest experience is best. Default should be to reject too-long-chain transaction from wallet and mempool. If the user wants to have long chains in wallet, that's fine but:
483 2017-03-16T19:12:32  <jnewbery> - it should be behind an explicit option
484 2017-03-16T19:12:32  <jnewbery> - user should understand that it could have unexpected impacts on things like getbalance()
485 2017-03-16T19:13:11  <gmaxwell> Transactions simply failing to create due to inexplicable internal things that the user does not understand and cannot easily understand is not a good expirence at all.
486 2017-03-16T19:13:16  <morcos> well look, this thing is an option, so its kind of ridiculous to spend this much time discussing the default.  The solution no matter whether we change the default or not is more announcing of the effects in either case
487 2017-03-16T19:13:36  <gmaxwell> We were already getting complaints about inexplicable failures before.
488 2017-03-16T19:13:56  <gmaxwell> Many people do not have adequate error handling to deal with a sendtoaddress failing when the balance was sufficient.
489 2017-03-16T19:13:57  <morcos> But too long a chain, try again later is explicable
490 2017-03-16T19:14:13  <sipa> gmaxwell: i think seeing your balance going down inexplicably is worse than inexplicably failing to create a transaction (at least there can be an explanation message)
491 2017-03-16T19:14:32  <gmaxwell> I agree the balance is screwed up. But _that_ is the issue, not the rest.
492 2017-03-16T19:14:45  <jnewbery> take this discussion offline? I'm happy to receive feedback in #10015
493 2017-03-16T19:14:45  <instagibbs> Either way we can buff up the error messages to be far less scary, especially in this case.
494 2017-03-16T19:14:47  <gribble> https://github.com/bitcoin/bitcoin/issues/10015 | Wallet should reject long chains by default by jnewbery · Pull Request #10015 · bitcoin/bitcoin · GitHub
495 2017-03-16T19:15:15  <gmaxwell> sipa: how about we remove all ability to sends funds entirely, then there never will be balance confusion?
496 2017-03-16T19:15:20  <sipa> gmaxwell: come on
497 2017-03-16T19:15:24  <morcos> well i wasn't implying we shouldn't discuss here, its kind of hard to have this discussion on a PR
498 2017-03-16T19:15:58  *** JackH has quit IRC
499 2017-03-16T19:16:00  <morcos> gmaxwell: the balance issue is not easy to solve
500 2017-03-16T19:16:32  <sipa> sure, if balance was redefined completely we may be able to avoid that issue, but i don't even know where to start
501 2017-03-16T19:16:45  <morcos> i just see both choices as non-optimal and i think we should pick one and try to make it as clear to users as possible
502 2017-03-16T19:16:53  <gmaxwell> This is a sign that our current definition is just broken. It should not be so tightly coupled to the mempool.
503 2017-03-16T19:16:57  <morcos> i thought that previously we had picked, and maybe failed at the making it clear
504 2017-03-16T19:17:19  <jonasschnelli> I'd say lets pick what serves more user... and the default = true seems to be the better choice...but I don't have numbers to proof that.
505 2017-03-16T19:17:21  <bsm1175322> One could create a RBF replacement transaction instead of a chain...
506 2017-03-16T19:17:35  <gmaxwell> (like how is the software even supposted to be usable to people that don't have a mempool? -- this is a supported configuration!)
507 2017-03-16T19:17:37  <sipa> gmaxwell: even if it is not tightly coupled with the mempool, we need a means of estimating whether it could confirm
508 2017-03-16T19:17:47  <morcos> yep, our time would be better spent extending bumpfee to work on chains
509 2017-03-16T19:18:13  <gmaxwell> or finding a way to eliminate the chain limit.
510 2017-03-16T19:18:25  <jnewbery> morcos: if the default is false (accept long chains) then it's very difficult to communicate to the user what the problem is. If we reject long chains then at least we can send a helpful error to the user
511 2017-03-16T19:18:31  <sipa> gmaxwell: i'm not convinced the chain limit itself is the only problem here
512 2017-03-16T19:18:35  <morcos> i suppose i do agree with gmaxwell thought that i always just took our balance calculation as gospel, but maybe it is kind of silly
513 2017-03-16T19:19:12  <gmaxwell> sipa: clearly not, because apparently we'll report a balance way off if you don't have a mempool! :)
514 2017-03-16T19:19:15  <jtimon> suggested topic: what's the current state on finally removing accounts?
515 2017-03-16T19:19:16  <luke-jr> bsm1175322: +1
516 2017-03-16T19:19:31  <gmaxwell> (er it's clearly not the only problem!)
517 2017-03-16T19:20:18  <sipa> gmaxwell: if you don't rely on the mempool, it's not that hard i think to make the wallet double count
518 2017-03-16T19:20:56  <wumpus> right, the wallet can't detect conflicting transactions itself
519 2017-03-16T19:20:56  <sipa> that would be great to fix, but i don't know how
520 2017-03-16T19:21:08  <gmaxwell> good thing there aren't any wallets in the bitcoin system without mempools.
521 2017-03-16T19:21:21  <wumpus> so if it sends a transaction, and someone malleates it and it would receive the malleated version back, it'd count that double
522 2017-03-16T19:21:22  <morcos> sipa: but a better balance calculation would be to evaluate net changes on a per tx basis
523 2017-03-16T19:21:28  <sipa> gmaxwell: wallets that don't spend unconfirmed change don't have this problem
524 2017-03-16T19:21:30  <morcos> and not consider the debits and credits separately
525 2017-03-16T19:21:32  <wumpus> it would work if it wouldn't count unconfirmed transactions
526 2017-03-16T19:21:46  <sipa> morcos: oh, you mean like the account system? *ducks*
527 2017-03-16T19:21:54  <wumpus> exactly, we have an option for that already
528 2017-03-16T19:22:01  <gmaxwell> sipa: no such wallet exists in the wild. (beyond bitcoin core users who have changed their settings and a few industrial users)
529 2017-03-16T19:23:08  <morcos> sipa: sigh.. no i mean properly..  there is no reason to assume a sent tx not in your mempool should debit your input but not credit your change output.  thats just broken.
530 2017-03-16T19:23:13  <morcos> at worst it should do both
531 2017-03-16T19:23:21  <morcos> only gets complicated if its a mixed debit tx
532 2017-03-16T19:23:48  *** Chris_Stewart_5 has quit IRC
533 2017-03-16T19:23:59  <gmaxwell> well it's showing a worse case balance, which is a thing you can rationally choose to do... but it's confusing to users esp with no other information available elsewhere.
534 2017-03-16T19:24:05  <sipa> gmaxwell: i don't know how to give an accurate unconfirmed balance without a mempool
535 2017-03-16T19:24:09  <morcos> actually, maybe gmaxwell is right.. maybe we can just fix that in our existing system?
536 2017-03-16T19:24:32  <morcos> gmaxwell: how is that worst case, how is that balance even achievable?
537 2017-03-16T19:24:38  <gmaxwell> Unfortunately, malleablity is still a thing.
538 2017-03-16T19:25:16  <gmaxwell> morcos: It's not achievable. But the estimation pattern of including non-mempool debits but not credits is a worst case estimator generally.
539 2017-03-16T19:25:17  <morcos> yes, but you can't end up with the debit and not the credit.. you can end up with the debit and you're momentarily confused how to spend the credit, but it's still your credit
540 2017-03-16T19:25:19  <sipa> without malleability maybe this problem becomes easier
541 2017-03-16T19:25:31  <gmaxwell> sometimes you have a non-mempool debit which will still go through.
542 2017-03-16T19:25:32  *** Guest53633 has joined #bitcoin-core-dev
543 2017-03-16T19:25:50  <luke-jr> sipa: are you including the wallet's storage of txs as "mempool"?
544 2017-03-16T19:25:56  <sipa> luke-jr: no
545 2017-03-16T19:26:27  *** Guest53633 has quit IRC
546 2017-03-16T19:26:28  *** Guest53633 has joined #bitcoin-core-dev
547 2017-03-16T19:26:29  <gmaxwell> I think any change estimation issue goes away if you assume non-malleablity and no concurrent use of the same keys.
548 2017-03-16T19:26:32  *** Guest53633 is now known as schmidty
549 2017-03-16T19:26:43  <gmaxwell> er balance estimation.
550 2017-03-16T19:27:20  <sipa> luke-jr: i mean a mempool which is kept consistent with the block chain - i guess you can simulate that inside the wallet, but it risks missing things that depend on unconfirmed transactions which don't involve you
551 2017-03-16T19:27:33  <gmaxwell> I find it hard to believe that the current behavior won't cause wildly wrong balances in other cases.  In particular, what happens to your balance when you pay something that falls out of the mempool due to low fees? same deal.
552 2017-03-16T19:27:52  <gmaxwell> Chaning the behavior for long chains will do nothing for that, just covers up the fundimentally bad behavior.
553 2017-03-16T19:28:35  <sipa> right, the expected behaviour there is that you use abandontx to correct the balance
554 2017-03-16T19:28:38  <gmaxwell> maybe it's not reasonably possible to fix completely in the presence of malleablity. The best thing with malleablity still around might be presenting a pending balance.
555 2017-03-16T19:28:41  <jtimon> sipa: but there will still be malleability for old txs, no? I don't undesrtand the discussion well enough...
556 2017-03-16T19:29:11  <sipa> gmaxwell: maybe people just don't hit the "falls out of mempool" case, and only hit chain length limits
557 2017-03-16T19:29:16  <gmaxwell> sipa: well you can use abandon in this case too. (though thats a pretty bad expirence, spend a cent, then hours later 100 btc vanishes from your balance? )
558 2017-03-16T19:29:28  <jonasschnelli> jtimon: The main user issue is described here: #9752
559 2017-03-16T19:29:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9752 | Max unconfirmed chainlength · Issue #9752 · bitcoin/bitcoin · GitHub
560 2017-03-16T19:29:37  <sipa> maybe we should have some form of automatic abandoning...
561 2017-03-16T19:29:46  <morcos> sipa: noooooooooooo
562 2017-03-16T19:29:48  <gmaxwell> sipa: we previously had reports about txn falling out of the mempool.
563 2017-03-16T19:29:55  <sipa> or at least automatically stop counting as debit at some point
564 2017-03-16T19:29:56  <gmaxwell> sipa: AutoFraud(tm)
565 2017-03-16T19:30:26  <jonasschnelli> I agree with sipa, especially the non sendto* (or Qt) ones.
566 2017-03-16T19:30:39  <wumpus> fee bump is a better alternative to abandoning
567 2017-03-16T19:30:48  <gmaxwell> wumpus++
568 2017-03-16T19:31:03  <jonasschnelli> wumpus: yes. but adding new outputs would be a requirement then.
569 2017-03-16T19:31:12  <sipa> but if you stop counting as debit, while still excluding from unspent outputs, you risk even worse unexpected behaviour
570 2017-03-16T19:31:16  <BlueMatt> yes, better to not auto-abandon and do what other wallets are doing now - if you try to send with too low a fee, nag the user really loudly to make it rbf-able
571 2017-03-16T19:31:19  <morcos> i'd be happy to discuss another time whether we can make some slight improvements to our balance estimation..  i guess i think it wouldn't be that hard... next time i have time i'll look closer
572 2017-03-16T19:31:33  <gmaxwell> BlueMatt: yes, what electrum does is reasonable there.
573 2017-03-16T19:31:52  <wumpus> abandoning is dangerous, there is no guarantee that everyone forgot the transaction, so the user may send the tx again with different outputs and then it goes through twice oops
574 2017-03-16T19:32:22  <jonasschnelli> The reminds me of the problem that BIP125 doesn't explicit mention a recommended nSequence nr. Electrum was using 0, Core intmax-2. (privacy)
575 2017-03-16T19:32:29  <sipa> right, i take back my suggestion to auto-abandom
576 2017-03-16T19:32:47  <BlueMatt> auto-bump, otoh.....
577 2017-03-16T19:32:54  <sipa> yeah...
578 2017-03-16T19:33:07  <wumpus> sipa: from a viewpoint of the user it's what they want, for the transaction to 'just disappear', bitcoin just makes that very difficult
579 2017-03-16T19:33:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
580 2017-03-16T19:33:16  <morcos> yeah auto bump should be 0.15 priority
581 2017-03-16T19:33:29  <gmaxwell> precomputed bumps with locktimes were always an idea I liked... doesn't really do great with spending unconfirmed change.
582 2017-03-16T19:33:38  <jonasschnelli> morcos: with plenty of pre-signed transactions?
583 2017-03-16T19:33:56  *** LeMiner has joined #bitcoin-core-dev
584 2017-03-16T19:34:18  <morcos> spending unconfirmed change is doable i think...  complicated, but you just stop bumping the first and start bumping the 2nd with CPFP calculations
585 2017-03-16T19:34:22  <BlueMatt> esp given miners can freely malleate it out from under you
586 2017-03-16T19:34:42  <gmaxwell> without malleablity basically none of these change handling issues would exist, I think.
587 2017-03-16T19:35:05  <gmaxwell> as you'd never have a case where you might double count your own funds.
588 2017-03-16T19:35:32  <wumpus> unfortunately we're stuck with malleability
589 2017-03-16T19:35:42  <morcos> not if we use flextrans
590 2017-03-16T19:35:49  <morcos> (sorry)
591 2017-03-16T19:35:49  <sipa> right, no from-self transaction in your wallet could credit you without you having signed for it
592 2017-03-16T19:35:51  <gmaxwell> hah
593 2017-03-16T19:35:55  <jonasschnelli> heh
594 2017-03-16T19:35:58  <wumpus> flextrans, lol
595 2017-03-16T19:36:06  <BlueMatt> trolol
596 2017-03-16T19:36:09  <gmaxwell> morcos: I made the remove all sending ability quip above!
597 2017-03-16T19:36:48  <gmaxwell> well we really haven't pushed to get malleablity fixed as a group... just put the fix out there.
598 2017-03-16T19:37:06  * sipa casually mentions segwit
599 2017-03-16T19:37:23  <morcos> ok... we're going off the rails. now.. maybe next topic.. and we revisit this in a week after thinking through both avenues
600 2017-03-16T19:37:27  <sipa> ok
601 2017-03-16T19:37:30  <BlueMatt> ack
602 2017-03-16T19:37:31  <gmaxwell> Sounds great.
603 2017-03-16T19:37:35  <jnewbery> yep
604 2017-03-16T19:37:42  <jonasschnelli> While we are touching the wallet... can we make progress on #9294?
605 2017-03-16T19:37:43  <wumpus> #topic status of removal of account system
606 2017-03-16T19:37:46  <gmaxwell> Sorry for being a PITA. :)
607 2017-03-16T19:37:46  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
608 2017-03-16T19:37:53  <jonasschnelli> wumpus: okay.
609 2017-03-16T19:37:55  <wumpus> can be really short there: no advances since last time we've discussed that
610 2017-03-16T19:38:06  <BlueMatt> jonasschnelli: that sounds like a should-review-this-week
611 2017-03-16T19:38:08  <wumpus> I should really pick up https://github.com/bitcoin/bitcoin/pull/7729
612 2017-03-16T19:38:23  <BlueMatt> wumpus: yes, this should definitely happen for 0.15, imo
613 2017-03-16T19:38:26  <gmaxwell> jonasschnelli: do we have a project setup to track things that change the wallet format in incompatible ways?
614 2017-03-16T19:38:34  <wumpus> as we need a label API first before even thinking about deprecating accounts
615 2017-03-16T19:38:45  <jonasschnelli> gmaxwell: not yet.
616 2017-03-16T19:38:47  <wumpus> BlueMatt: I agree, though multiwallet has higher priority for me
617 2017-03-16T19:39:03  <gmaxwell> multiwallet++++++++++++++++++++++++++++++divide by zero error
618 2017-03-16T19:39:05  <wumpus> I intended to pick up multiwallet this week, but eh shit happened
619 2017-03-16T19:39:18  <BlueMatt> ok, so lets list reviews to prioritize this week?
620 2017-03-16T19:39:33  <sipa> my focus will be leveldb mempool reduction
621 2017-03-16T19:39:44  <BlueMatt> jonasschnelli: mentioned 9294, I'm still super blocked on 9725
622 2017-03-16T19:40:06  *** laurentmt has quit IRC
623 2017-03-16T19:40:10  <wumpus> #8694
624 2017-03-16T19:40:13  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
625 2017-03-16T19:40:15  <sipa> #9294 #9725
626 2017-03-16T19:40:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
627 2017-03-16T19:40:18  <jonasschnelli> 9294 would need direction if the performance drawback is acceptable. IMO yes.
628 2017-03-16T19:40:20  <gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
629 2017-03-16T19:40:23  <BlueMatt> yea, was just looking for that one wumpus
630 2017-03-16T19:40:38  <wumpus> that's the next step toward multiwallet, though luke-jr and I have some disagreement about specifics about implementation
631 2017-03-16T19:40:39  <stevenroose> My btcd testnet node recently got a softfork deployment on versionbit 28. Is that this dummy deployment from bitcoind?
632 2017-03-16T19:40:40  <stevenroose> v
633 2017-03-16T19:40:40  <gmaxwell> sipa: you mean the "make defaults work on odroid c2 again" problem?
634 2017-03-16T19:40:41  <stevenroose> https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L190
635 2017-03-16T19:40:42  <jonasschnelli> I'd like to continue with HD restore... but 9294 seems to be required first
636 2017-03-16T19:40:45  <wumpus> but that it needs to happen is clear
637 2017-03-16T19:41:01  <jtimon> wumpus: oh, right, we need 7729 first
638 2017-03-16T19:41:05  <sipa> gmaxwell: no, i mean fix the silly continuous allocation of leveldb memory
639 2017-03-16T19:41:14  <gmaxwell> stevenroose: that is likely doofsus still signling 'bip 109' on testnet. (even though nothing implements it anymore)
640 2017-03-16T19:41:43  <wumpus> jonasschnelli: yes the HD chain split *defnitely* needs to be in 0.15
641 2017-03-16T19:41:48  <gmaxwell> sipa: so memory reduction not mempool reduction.
642 2017-03-16T19:41:50  <wumpus> jonasschnelli: it's sad it missed 0.14
643 2017-03-16T19:42:06  <jonasschnelli> wumpus: merging sooner should allow more perofmance improvemnts before 0.15.
644 2017-03-16T19:42:06  <sipa> gmaxwell: lol. yes
645 2017-03-16T19:42:21  <jonasschnelli> *performance improvements
646 2017-03-16T19:42:22  <gmaxwell> jonasschnelli: you can still implement lookahead scanning without the split.
647 2017-03-16T19:42:29  <wumpus> jonasschnelli: agree, will take a look at it
648 2017-03-16T19:42:32  <stevenroose> gmaxwell, yeah I read about bip109 as well when I googled the versionbit. So that means that 95% of testnett blocks the last few weeks were mined by people trolling about bip109?
649 2017-03-16T19:42:40  <jonasschnelli> gmaxwell: Yes. But I don't want to go to the rebase-hell. :)
650 2017-03-16T19:42:47  <wumpus> jonasschnelli: at some point we should merge something so that it can be improved
651 2017-03-16T19:43:06  <wumpus> right, it's frustrating to keep non-trivial things up to date with all the code churn
652 2017-03-16T19:43:25  <luke-jr> wumpus: I don't necessarily disagree with your points, just that they're factoring unrelated to multiwallet itself IMO
653 2017-03-16T19:43:26  <achow101> stevenroose: not now or here. ask in #bitcoin-dev, there's a meeting going on here right now
654 2017-03-16T19:43:28  <jtimon> I wouldn't mind some re-reviews on #8855 (previously #6907), it's simple
655 2017-03-16T19:43:30  <gmaxwell> stevenroose: no, it got 'activated' eons ago. then the miner signaling it mined BIP109 invalid blocks (because their implementation was broken) and forked classic off (until classic ripped out 109)
656 2017-03-16T19:43:30  <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
657 2017-03-16T19:43:30  <jonasschnelli> But multiwallet will be also my prio for 0.15. I start reviewing more soon.
658 2017-03-16T19:43:33  <gribble> https://github.com/bitcoin/bitcoin/issues/6907 | Chainparams: Use a regular factory for creating chainparams by jtimon · Pull Request #6907 · bitcoin/bitcoin · GitHub
659 2017-03-16T19:43:42  <jonasschnelli> The whole Qt part is unsolved IMO.
660 2017-03-16T19:44:00  <jonasschnelli> The general concept of switching/opening/closing/creating wallets
661 2017-03-16T19:44:06  <stevenroose> achow101, my apologies
662 2017-03-16T19:44:07  <luke-jr> jonasschnelli: no, I have a branch for that
663 2017-03-16T19:44:10  <wumpus> jonasschnelli: I'd be happy to have it in JSONRPC already
664 2017-03-16T19:44:11  <luke-jr> jonasschnelli: it's 2 PRs away
665 2017-03-16T19:44:19  <wumpus> jonasschnelli: no need to block anything on GUI support
666 2017-03-16T19:44:23  <jonasschnelli> luke-jr: great!
667 2017-03-16T19:44:30  <jonasschnelli> wumpus: Sure...
668 2017-03-16T19:44:48  <jonasschnelli> But in general the low level stuff should conceptually fits the UI goals
669 2017-03-16T19:44:55  <wumpus> even small steps forward are worthwhile in this regard
670 2017-03-16T19:44:58  <wumpus> jonasschnelli: sure
671 2017-03-16T19:45:13  <jonasschnelli> Yes. Multiwallet was hold back long enought... I'm happy with every simple babystep
672 2017-03-16T19:45:18  <luke-jr> jonasschnelli: Knots has actually included multiwallet since 0.13, FWIW
673 2017-03-16T19:45:35  <jonasschnelli> luke-jr: Never used Knots. I probably should try it at least.
674 2017-03-16T19:46:46  <wumpus> ok, other topics?
675 2017-03-16T19:47:01  <jnewbery> running python rpc tests from `make check`?
676 2017-03-16T19:47:07  <kanzure> was someone asking about nulldummy versionbit?
677 2017-03-16T19:47:21  <luke-jr> isn't nulldummy deployed with segwit?
678 2017-03-16T19:47:34  <sipa> yes
679 2017-03-16T19:48:24  <achow101> I've been getting some reports about people's nodes running out of memory. perhaps we need to publish a "minimum spec" so people know what to expect if they don't meet that
680 2017-03-16T19:48:34  <cfields> jnewbery: +1. we were discussing this a few min ago. That makes "make check" dependent on python3 though (apparently). Not sure if wumpus is ok with that
681 2017-03-16T19:48:47  <wumpus> cfields: I don't mind
682 2017-03-16T19:49:03  <wumpus> cfields: the only thing I worry about is the slowness of the RPC tests
683 2017-03-16T19:49:43  <jonasschnelli> What's the benefits of adding the rpc's to `make check`?
684 2017-03-16T19:49:46  <wumpus> 'make check' should ideally do fairly quick checks, some of the RPC tests classify as that, but the whole suite takes maybe too long
685 2017-03-16T19:49:57  <gmaxwell> make check is currently not quick at all.
686 2017-03-16T19:50:08  <gmaxwell> I think on my system it actually takes similar time to the whole rpc checks.
687 2017-03-16T19:50:09  <wumpus> gmaxwell: secp256k1 is part of that :p
688 2017-03-16T19:50:18  <gmaxwell> let me revise.
689 2017-03-16T19:50:21  <cfields> wumpus: same. But lately I've been coming around to gmaxwell's point that they're a bulk of our tests, so it's kinda a disservice for people to assume that "make check" and all is good
690 2017-03-16T19:50:32  <gmaxwell> the unit tests themselves take almost as long as the rpc tests.
691 2017-03-16T19:50:36  <gmaxwell> and are _far_ less useful.
692 2017-03-16T19:50:36  <jonasschnelli> Indeed. Adding another 20min rpc test will result in nobody running make check anymore
693 2017-03-16T19:50:38  <wumpus> it does the extensive tests for secp256k1, which take quite a while
694 2017-03-16T19:50:48  <gmaxwell> jonasschnelli: Does anyone but us run make check now? :P
695 2017-03-16T19:50:49  <wumpus> gmaxwell: that's certainly not true here
696 2017-03-16T19:50:50  <cfields> wumpus: also, this would parallelize the tests. So the boost tests and rpc would run at the same time
697 2017-03-16T19:50:51  <jtimon> jnewbery: I would prefer a diferent target, you could still do make check tests, or only make check or only make tests
698 2017-03-16T19:50:55  <luke-jr> I'd rather `make check` be comprehensive than quick tbh. the default RPC test suite seems like an okay compromise.
699 2017-03-16T19:50:57  <wumpus> yes, I run make check a lot
700 2017-03-16T19:51:00  <jonasschnelli> gmaxwell: I hope so... but i doubt.
701 2017-03-16T19:51:12  <wumpus> cfields: ok that's pretty cool
702 2017-03-16T19:51:15  <gmaxwell> wumpus: the secp256k1 tests are adjustable and can basically take as little or as much time as you like, we could make it arbitarily fast.
703 2017-03-16T19:51:28  <jnewbery> I could select a subset of fast rpc tests if you think the standard list is too slow
704 2017-03-16T19:51:39  <jonasschnelli> I guess not even the gitian system runs make check
705 2017-03-16T19:51:42  <gmaxwell> wumpus: though I'd like to move some more of the secp256k1 tests to runtime, it isn't like distributors actually make check. :(
706 2017-03-16T19:51:47  <wumpus> gmaxwell: I dont think running the secp256k1 tests thoroughly is a bad idea at all
707 2017-03-16T19:51:53  <wumpus> gmaxwell: helps catch compiler bugs and such
708 2017-03-16T19:51:55  <jonasschnelli> though a bit more complex because of the platforms.
709 2017-03-16T19:51:56  <jtimon> wumpus: maybe the tests to run with make should be all but excluding prunning.py?
710 2017-03-16T19:52:13  <gmaxwell> yes, I think they're important, though we could move some of that to simple startup time. The most critical checks are very fast.
711 2017-03-16T19:52:37  <wumpus> e.g. broken signing is very, very bad
712 2017-03-16T19:52:43  <gmaxwell> I worry a lot about compiler bugs, our current make check is woefully inadequate (except the libsecp256k1 part, granted. :P )
713 2017-03-16T19:52:51  <jtimon> cfields: but the unittests themelseves don't run in parallel like the rpc/py tests, right?
714 2017-03-16T19:53:07  <gmaxwell> wumpus: (similar to how I nagged you to make those rng tests runtime and you did...)
715 2017-03-16T19:53:10  <jonasschnelli> jtimon: not that i know
716 2017-03-16T19:53:11  <gmaxwell> (thank you)
717 2017-03-16T19:53:21  <wumpus> jtimon: parallelism at multiple levels doesn't make much sense, there's only so many cores to go around
718 2017-03-16T19:53:24  <jtimon> also, make check tests -j10 should pass -j10 down to the rpc-tester, right?
719 2017-03-16T19:53:35  <cfields> jtimon: correct, we'd never survive that
720 2017-03-16T19:53:39  <gmaxwell> wumpus: we could probably define a subset of rpc tests that are fast and more useful than the unit tests.
721 2017-03-16T19:53:42  <cfields> jtimon: ooh yes, that'd be really nice
722 2017-03-16T19:54:00  <wumpus> gmaxwell: yup. don't know if you saw the clang fsafe-stack issue that messes up deterministic signing
723 2017-03-16T19:54:04  <jtimon> wumpus: well, current make check could be faster, I compile very fast, but then it gests stuck at 1 core running the tests
724 2017-03-16T19:54:25  <jtimon> half the time I wait more for the unittests than to compile
725 2017-03-16T19:54:40  <gmaxwell> wumpus: I didn't.
726 2017-03-16T19:54:44  <wumpus> jtimon: but cfields proposes running (some of) the qa tests at the same time
727 2017-03-16T19:54:47  <wumpus> gmaxwell: let me dig it up
728 2017-03-16T19:54:57  <gmaxwell> Has anyone recently 'profiled' the tests to see where time is being spent?
729 2017-03-16T19:55:12  <gmaxwell> I bet we have cases where 20% of the time is checking if addition works or something. :P
730 2017-03-16T19:55:14  <jonasschnelli> gmaxwell: unit or rpc?
731 2017-03-16T19:55:16  <jnewbery> gmaxwell: unit tests or rpc tests
732 2017-03-16T19:55:16  <wumpus> gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445
733 2017-03-16T19:55:19  <gmaxwell> jnewbery: both.
734 2017-03-16T19:55:33  <jnewbery> I've profiled rpc tests. A lot of time is spent in stopnode()
735 2017-03-16T19:55:38  <gmaxwell> wumpus: holy fuck!
736 2017-03-16T19:55:53  <wumpus> both frameworks measure the time spent in every test, so profiling at that level is easy
737 2017-03-16T19:55:58  <jtimon> wumpus: well, I suggest a different target, but if they don't depend on each other, I guess they would run "at the same time"
738 2017-03-16T19:56:06  <gmaxwell> wumpus: good for tests. (but as I said, we should make some of those runtime too)
739 2017-03-16T19:56:08  <wumpus> I don't remember by heart which ones, though
740 2017-03-16T19:56:12  <morcos> i believe the rpc tests could also be made faster if tx relay had a different poisson distribution for regtest or something... i seem to remember that being an issue
741 2017-03-16T19:56:17  <cfields> wumpus: whoa. Isn't that default for clang now? Or proposed, at least?
742 2017-03-16T19:56:51  <gmaxwell> regardless of the specific example, compiler bugs are a real thing.
743 2017-03-16T19:57:05  <wumpus> cfields: I think it's going to be more widely enabled, yes, though AFAIK not yet. I only caught it because cloudabi already has it as default
744 2017-03-16T19:57:06  <cfields> jnewbery: i'd be interested in your findings there
745 2017-03-16T19:57:06  <gmaxwell> (though seeing them in rather boring C code is depressing)
746 2017-03-16T19:57:48  <gmaxwell> wumpus: in any case thats the best news all day! I've complained many times that our tests must suck because we've not found any miscompliation bugs.
747 2017-03-16T19:57:49  <wumpus> (test_bitcoin -log_level=test_suite shows which unit tsts take so long. most are really fast! )
748 2017-03-16T19:58:10  <gmaxwell> wumpus: finally some evidence that our tests are potentially okay. :P
749 2017-03-16T19:58:12  <wumpus> gmaxwell: heh
750 2017-03-16T19:58:32  <jnewbery> ok, sounds like there's no fundamental objection to at least doing some rpc tests in make check. I'll open a PR and we can continue discussion there.
751 2017-03-16T19:58:53  <wumpus> gmaxwell: and yes doing some quick secp256k1 tests at runtime would make a lot of sense
752 2017-03-16T19:59:03  <wumpus> gmaxwell: basic sanity is fairly easy to check
753 2017-03-16T19:59:07  <gmaxwell> jnewbery: yes, and we should look at time measurements and rebalance the tests to be more useful.
754 2017-03-16T19:59:12  <jnewbery> also, once 9956 is merged we can stop calling them rpc tests!
755 2017-03-16T19:59:27  <gmaxwell> wumpus: I have a branch somewhere that adds some runtime selftests, but I think I got a bit carried away and put it aside. :P
756 2017-03-16T19:59:28  <jonasschnelli> jnewbery: Yes. I'd like to see that merged.
757 2017-03-16T19:59:31  <wumpus> jnewbery: no, no fundamental objection. Just about speed but that doesn't depend on the language/framework
758 2017-03-16T19:59:40  <wumpus> jnewbery: +1
759 2017-03-16T20:00:01  <jtimon> jnewbery: I still heard no reason against adding a new target instead of reusing check
760 2017-03-16T20:00:10  <wumpus> some of the qa tests are really fast, some of the unit tests really slow, indeed should rebalance testing bang for buck
761 2017-03-16T20:00:19  <gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/217  (but I'd probably toss that and take a somewhat different approach now)
762 2017-03-16T20:00:22  <wumpus> it's time
763 2017-03-16T20:00:27  <wumpus> #endmeeting
764 2017-03-16T20:00:27  <lightningbot> Meeting ended Thu Mar 16 20:00:27 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
765 2017-03-16T20:00:27  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-16-19.01.html
766 2017-03-16T20:00:27  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-16-19.01.txt
767 2017-03-16T20:00:27  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-16-19.01.log.html
768 2017-03-16T20:00:27  <gmaxwell> thanks all!
769 2017-03-16T20:00:45  <jonasschnelli> wumpus: If you run with wallet, you have a basic EC sanity check over VerifyPubKey().
770 2017-03-16T20:01:04  <jonasschnelli> But we should probably extend it and add call it from non-wallet init parts
771 2017-03-16T20:01:05  <jnewbery> jtimon: I like the idea of `make tests` for the full suite, but I think `make check` should include some rpc tests
772 2017-03-16T20:01:18  <jtimon> jnewbery: oh, I had missed 9956, thanks for pointing it out
773 2017-03-16T20:01:43  <gmaxwell> jonasschnelli: a special test function could get a much more comprehensive test in not much time.
774 2017-03-16T20:01:52  <cfields> jnewbery: do you happen to still have any of those profiles showing slow stopnode() ?
775 2017-03-16T20:02:16  <jtimon> jnewbery: mhmm, why not make tests includes some python tests (maybe most of them) but make check none of them?
776 2017-03-16T20:02:31  <jonasschnelli> gmaxwell: I really wonder now why we haven't added a simple runtime EC sanity test...
777 2017-03-16T20:02:36  <jnewbery> jtimon: I've got some nits from cfields to address on 9956. Very happy for other people to review after that
778 2017-03-16T20:03:06  <jnewbery> cfields: I believe I have them lying around somewhere. Let me dig them out
779 2017-03-16T20:03:13  <jonasschnelli> I mean coffee machines do "runtime tests" and a faulty EC subsystem can cause far more troubles
780 2017-03-16T20:03:36  <cfields> jnewbery: thanks. I would assume that it's just waiting for the threads to stop. But I'm curious to see what they're spinning on
781 2017-03-16T20:04:37  <jtimon> so no answer? everybody seems to prefer reusing make check with some tests, but nobody seem to be able to explain why...
782 2017-03-16T20:05:18  <jnewbery> cfields: I think it just takes a long time (a few seconds) to stop a node. They're synchronous calls and stopnodes() will stop nodes in series rather than parallel. Some tests also do multiple stop-starts. It adds up.
783 2017-03-16T20:05:19  <jonasschnelli> The crazy think with the SafeStack issue in LLVM4.0 is that they are not willing to fix it for 4.0. It will be fixed for 4.0.1.
784 2017-03-16T20:06:39  <jnewbery> jtimon: patience :) I have no particular objection to either. What do you think the different use-cases are for `make check` and `make tests`? (ie under what circumstances should users *not* want to run a few quick python tests)
785 2017-03-16T20:06:45  <cfields> jnewbery: oh wait, you mean profiling on the python side?
786 2017-03-16T20:07:09  <jtimon> jnewbery: mostly giving the user more control on how much time he wants to spend running tests
787 2017-03-16T20:07:37  <jnewbery> yes. Oh, sorry you want profiling of the node's doing as it stops? I don't have that.
788 2017-03-16T20:07:50  <cfields> jnewbery: sorry, CConnman::Stop() used to be StopNode(). I thought that's what you were referencing.
789 2017-03-16T20:07:56  <jtimon> maybe it is the unittests they don't want to run for whatever reason
790 2017-03-16T20:08:16  *** Chris_Stewart_5 has quit IRC
791 2017-03-16T20:08:29  <instagibbs> jtimon, some people don't know the rpc tests exist, or think that rpc tests run when you call it
792 2017-03-16T20:08:49  <jnewbery> `make check` currently runs the unit tests. You'd change that so it doesn't run unit tests either? What would there be left for it to do?
793 2017-03-16T20:09:19  *** voyager_ has quit IRC
794 2017-03-16T20:09:21  <jnewbery> cfields: sorry name collision
795 2017-03-16T20:09:46  *** voyager_ has joined #bitcoin-core-dev
796 2017-03-16T20:12:50  *** JackH has joined #bitcoin-core-dev
797 2017-03-16T20:16:08  *** shesek has quit IRC
798 2017-03-16T20:16:31  <jtimon> instagibbs: and those people run make check?
799 2017-03-16T20:16:54  <instagibbs> jtimon, this happened just last week, so yes
800 2017-03-16T20:17:27  <instagibbs> from someone I expected knew this
801 2017-03-16T20:17:28  <jtimon> jnewbery: no, I mean those people could run "make tests" and run only the python tests, or "make check" only the unitttests or "make check tests" to run both
802 2017-03-16T20:17:33  <instagibbs> (n = 1 and all that)
803 2017-03-16T20:19:10  <jtimon> instagibbs: I think this can be fixed with docuentation about the new test target and the current check one instead of change check to match their expectations (which I assume was that all python tests were run with check, something nobody seems to be proposing)
804 2017-03-16T20:19:51  <jtimon> I just don't see the advantage in giving the user less control, sorry
805 2017-03-16T20:20:01  <jnewbery> jtimon: I think the shorter form `make check` (ie the one that most people will type) should run a cross section of all types of test (ie all unit plus some python). I'm not opposed to having other forms that run just the unit tests or just the python tests.
806 2017-03-16T20:21:20  <jtimon> make check is not shorter than make test, but whatever, why not think of another name for the new functionality and leave the option that only run unittests (if we're going to have one) with its current name?
807 2017-03-16T20:21:45  <instagibbs> jtimon, I don't really care a lot, just saying this problem does actually seem to exist
808 2017-03-16T20:21:51  <jtimon> anyway, I guess this is not so important to disccuss it so much
809 2017-03-16T20:22:05  <jnewbery> I also don't care too much on what we call it :)
810 2017-03-16T20:22:18  <jnewbery> but I'll make sure there's a way to just run unit tests
811 2017-03-16T20:22:25  <jtimon> instagibbs: just stating my preferred solution
812 2017-03-16T20:22:51  *** Sosumi has quit IRC
813 2017-03-16T20:23:23  <jtimon> jnewbery: cool
814 2017-03-16T20:30:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
815 2017-03-16T20:33:48  *** jtimon has quit IRC
816 2017-03-16T20:56:38  *** nemgun has quit IRC
817 2017-03-16T21:09:12  *** marcoagner has joined #bitcoin-core-dev
818 2017-03-16T21:13:05  *** dcousens has quit IRC
819 2017-03-16T21:14:12  *** droark has joined #bitcoin-core-dev
820 2017-03-16T21:27:06  *** jtimon has joined #bitcoin-core-dev
821 2017-03-16T21:33:27  <bitcoin-git> [bitcoin] jnewbery opened pull request #10017: [POC] combine_logs.py - aggregates log files from multiple bitcoinds during functional tests. (master...log_aggregator) https://github.com/bitcoin/bitcoin/pull/10017
822 2017-03-16T21:36:50  *** CubicEarth has joined #bitcoin-core-dev
823 2017-03-16T21:37:57  *** goksinen has joined #bitcoin-core-dev
824 2017-03-16T21:53:35  *** kadoban has quit IRC
825 2017-03-16T21:55:40  *** kadoban has joined #bitcoin-core-dev
826 2017-03-16T22:01:12  *** chjj has quit IRC
827 2017-03-16T22:05:20  *** Chris_Stewart_5 has quit IRC
828 2017-03-16T22:08:57  *** CubicEarth has quit IRC
829 2017-03-16T22:14:29  *** chjj has joined #bitcoin-core-dev
830 2017-03-16T22:16:13  *** CubicEarth has joined #bitcoin-core-dev
831 2017-03-16T22:25:56  *** Guyver2 has quit IRC
832 2017-03-16T22:45:02  *** goksinen has quit IRC
833 2017-03-16T22:50:35  *** CubicEarth has quit IRC
834 2017-03-16T22:57:03  *** laurentmt has joined #bitcoin-core-dev
835 2017-03-16T23:00:31  *** goksinen has joined #bitcoin-core-dev
836 2017-03-16T23:01:32  *** wasi has quit IRC
837 2017-03-16T23:01:55  *** wasi has joined #bitcoin-core-dev
838 2017-03-16T23:03:11  *** laurentmt has quit IRC
839 2017-03-16T23:05:27  *** goksinen has quit IRC
840 2017-03-16T23:08:19  *** afk11_ has quit IRC
841 2017-03-16T23:08:35  *** afk11_ has joined #bitcoin-core-dev
842 2017-03-16T23:08:49  *** wasi has quit IRC
843 2017-03-16T23:10:07  *** wasi has joined #bitcoin-core-dev
844 2017-03-16T23:18:29  *** jannes has quit IRC
845 2017-03-16T23:19:44  *** aalex has quit IRC
846 2017-03-16T23:19:53  *** dcousens has joined #bitcoin-core-dev
847 2017-03-16T23:37:35  *** dcousens has quit IRC
848 2017-03-16T23:47:09  *** goksinen has joined #bitcoin-core-dev
849 2017-03-16T23:48:45  *** dodomojo has joined #bitcoin-core-dev
850 2017-03-16T23:50:54  *** chjj has quit IRC
851 2017-03-16T23:51:34  *** goksinen has quit IRC
852 2017-03-16T23:59:55  *** dodomojo has quit IRC