1 2017-05-11T00:00:56  *** Giszmo has joined #bitcoin-core-dev
  2 2017-05-11T00:05:51  *** jcliff42 has quit IRC
  3 2017-05-11T00:06:02  *** d9b4bef9 has quit IRC
  4 2017-05-11T00:07:08  *** d9b4bef9 has joined #bitcoin-core-dev
  5 2017-05-11T00:12:46  *** AaronvanW has quit IRC
  6 2017-05-11T00:14:40  *** jcliff42 has joined #bitcoin-core-dev
  7 2017-05-11T00:15:00  *** jcliff42 has joined #bitcoin-core-dev
  8 2017-05-11T00:16:00  *** justanotheruser has joined #bitcoin-core-dev
  9 2017-05-11T00:32:41  *** dermoth has quit IRC
 10 2017-05-11T00:46:00  *** goksinen has joined #bitcoin-core-dev
 11 2017-05-11T00:50:23  *** goksinen has quit IRC
 12 2017-05-11T01:09:55  *** jcliff42 has quit IRC
 13 2017-05-11T01:14:11  *** Ylbam has quit IRC
 14 2017-05-11T01:26:04  *** gm2052 has quit IRC
 15 2017-05-11T01:27:21  *** gm2052 has joined #bitcoin-core-dev
 16 2017-05-11T01:28:41  *** justanotheruser has quit IRC
 17 2017-05-11T02:04:55  *** justanotheruser has joined #bitcoin-core-dev
 18 2017-05-11T02:08:29  *** jcliff42 has joined #bitcoin-core-dev
 19 2017-05-11T02:08:49  *** jcliff42 has joined #bitcoin-core-dev
 20 2017-05-11T02:10:19  *** jcliff42_ has joined #bitcoin-core-dev
 21 2017-05-11T02:12:10  *** goksinen has joined #bitcoin-core-dev
 22 2017-05-11T02:13:46  <bitcoin-git> [bitcoin] kallewoof opened pull request #10386: [wallet] Optional '-avoidreuse' flag which defaults to not reusing addresses in sends (master...feature-white-black-address) https://github.com/bitcoin/bitcoin/pull/10386
 23 2017-05-11T02:14:17  *** jcliff42_ has quit IRC
 24 2017-05-11T02:14:23  *** jcliff42 has quit IRC
 25 2017-05-11T02:17:01  *** goksinen has quit IRC
 26 2017-05-11T02:27:57  *** goksinen has joined #bitcoin-core-dev
 27 2017-05-11T02:30:02  *** gm2051 has joined #bitcoin-core-dev
 28 2017-05-11T02:32:17  *** goksinen has quit IRC
 29 2017-05-11T02:32:33  *** gm2052 has quit IRC
 30 2017-05-11T03:15:26  *** goksinen has joined #bitcoin-core-dev
 31 2017-05-11T03:20:27  *** goksinen has quit IRC
 32 2017-05-11T03:29:36  *** zooko has joined #bitcoin-core-dev
 33 2017-05-11T03:50:01  *** zooko has quit IRC
 34 2017-05-11T03:54:59  *** dermoth has joined #bitcoin-core-dev
 35 2017-05-11T04:04:43  *** zooko has joined #bitcoin-core-dev
 36 2017-05-11T04:06:02  *** d9b4bef9 has quit IRC
 37 2017-05-11T04:07:09  *** d9b4bef9 has joined #bitcoin-core-dev
 38 2017-05-11T04:12:37  *** Dyaheon has quit IRC
 39 2017-05-11T04:13:37  *** Dyaheon has joined #bitcoin-core-dev
 40 2017-05-11T04:14:55  *** tripleslash has quit IRC
 41 2017-05-11T04:18:07  *** tripleslash has joined #bitcoin-core-dev
 42 2017-05-11T04:29:33  *** paveljanik has quit IRC
 43 2017-05-11T04:30:21  *** zooko has quit IRC
 44 2017-05-11T04:32:16  *** niska has quit IRC
 45 2017-05-11T04:32:43  *** niska has joined #bitcoin-core-dev
 46 2017-05-11T04:35:10  *** tripleslash has quit IRC
 47 2017-05-11T04:38:46  *** tripleslash has joined #bitcoin-core-dev
 48 2017-05-11T04:47:48  *** tripleslash has quit IRC
 49 2017-05-11T04:49:26  *** annanay25 has quit IRC
 50 2017-05-11T04:49:36  *** annanay25 has joined #bitcoin-core-dev
 51 2017-05-11T04:50:11  *** tripleslash has joined #bitcoin-core-dev
 52 2017-05-11T05:02:39  *** tripleslash has quit IRC
 53 2017-05-11T05:04:07  *** tripleslash has joined #bitcoin-core-dev
 54 2017-05-11T05:16:56  *** goksinen has joined #bitcoin-core-dev
 55 2017-05-11T05:18:45  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a26280bc1415...7f2b9e0868f5
 56 2017-05-11T05:18:46  <bitcoin-git> bitcoin/master f203ecc Pavel Janík: Shadowing is not enabled by default, update doc accordingly.
 57 2017-05-11T05:18:46  <bitcoin-git> bitcoin/master 7f2b9e0 Wladimir J. van der Laan: Merge #10381: Shadowing warnings are not enabled by default, update doc accordingly...
 58 2017-05-11T05:19:16  <bitcoin-git> [bitcoin] laanwj closed pull request #10381: Shadowing warnings are not enabled by default, update doc accordingly (master...20170510_Wshadow_not_enabled_by_default) https://github.com/bitcoin/bitcoin/pull/10381
 59 2017-05-11T05:21:27  *** goksinen has quit IRC
 60 2017-05-11T05:29:40  *** ckm has joined #bitcoin-core-dev
 61 2017-05-11T05:32:45  *** goksinen has joined #bitcoin-core-dev
 62 2017-05-11T05:37:23  *** goksinen has quit IRC
 63 2017-05-11T05:58:55  *** Victorsueca has quit IRC
 64 2017-05-11T06:06:27  *** Ylbam has joined #bitcoin-core-dev
 65 2017-05-11T06:17:03  *** Dyaheon has quit IRC
 66 2017-05-11T06:20:50  *** Dyaheon has joined #bitcoin-core-dev
 67 2017-05-11T06:38:38  *** marcoagner has quit IRC
 68 2017-05-11T06:38:47  *** marcoagn1 has joined #bitcoin-core-dev
 69 2017-05-11T07:04:42  <ckm> anybody know why bitcoin started on microsoft/windows?
 70 2017-05-11T07:05:01  <ckm> seems odd for an open-source project
 71 2017-05-11T07:08:34  <kallewoof> Probably because Satoshi was using Windows when he wrote it
 72 2017-05-11T07:09:47  *** EagleTM has joined #bitcoin-core-dev
 73 2017-05-11T07:14:18  *** CubicEarth has joined #bitcoin-core-dev
 74 2017-05-11T07:15:44  <ckm> okay, yeah, that's a pastability. not sure though. maybe it was that the alternatives were less prevalent then, so it could have been strategic to get more miners. i kinda want a logical explanation. like it could have been a statement like hacking microsoft/windows in a phoenix type of way. hmm. your thoughts?
 75 2017-05-11T07:22:55  <sipa> my assumption is that satoshi or whoever wrote the first code was a windows programmer
 76 2017-05-11T07:23:10  <sipa> the naming style of variables etc is consistent with that
 77 2017-05-11T07:27:33  *** waxwing has quit IRC
 78 2017-05-11T07:29:09  <ckm> okay going with that then is there any indication that this was a microsoft job? they do seem to be the most supportive big tech company, including support in visual basic, openly wanting a cashless money system, and with statements of public approval
 79 2017-05-11T07:33:27  *** goksinen has joined #bitcoin-core-dev
 80 2017-05-11T07:37:57  *** goksinen has quit IRC
 81 2017-05-11T07:59:08  <sipa> offtopic
 82 2017-05-11T08:05:30  <wumpus> there are likely more windows programmers than unix programmers in the world, so the chance of a software project starting as windows software is fairly high. Seems kind of a big leap to say it's a microsoft job then. If it had started as linux project, would you have personally implicated Linus?
 83 2017-05-11T08:05:35  <wumpus> but yes, offtopic, #bitcoin please
 84 2017-05-11T08:06:55  *** shockoo has joined #bitcoin-core-dev
 85 2017-05-11T08:14:00  *** jannes has joined #bitcoin-core-dev
 86 2017-05-11T08:16:40  <ckm> i just looked through all the original code and it doesn't seem like a "microsoft job" from the comments et cettera. i wasn't very into computers, i thought linux was hard to use back then, so i was using windows/mac but a programmer would i think have been able to use it. although it would be fairest to the public to make a windows version so everybody could in theory mine the genisis block.
 87 2017-05-11T08:16:52  <ckm> and sorry for offtopic i will switch over to there, thanks!
 88 2017-05-11T08:20:42  *** i3-c3 has joined #bitcoin-core-dev
 89 2017-05-11T08:28:51  *** waxwing has joined #bitcoin-core-dev
 90 2017-05-11T08:31:23  *** timothy has joined #bitcoin-core-dev
 91 2017-05-11T08:35:24  *** CubicEarth has quit IRC
 92 2017-05-11T08:36:03  *** CubicEarth has joined #bitcoin-core-dev
 93 2017-05-11T08:37:42  *** CubicEarth has quit IRC
 94 2017-05-11T08:45:12  *** ckm has quit IRC
 95 2017-05-11T08:57:49  *** AaronvanW has joined #bitcoin-core-dev
 96 2017-05-11T08:57:49  *** AaronvanW has joined #bitcoin-core-dev
 97 2017-05-11T09:03:36  <jonasschnelli> Can anyone explain when a peer does relay its own CAddress to a connected peer? When I connect with mininode and inject a getaddr, I get now addr message
 98 2017-05-11T09:04:19  <wumpus> on incoming connections, yes
 99 2017-05-11T09:04:45  <jonasschnelli> wumpus: hmm... maybe I got fooled by the AddNewAddresses time penalty?
100 2017-05-11T09:05:12  <wumpus> sure, or maybe there's a bug, I don't know
101 2017-05-11T09:05:30  <jonasschnelli> Okay... i'll check.. maybe my local changes broke thinsg...
102 2017-05-11T09:05:40  <wumpus> it seems advertizing works, but the issues about IP changes not propagating are kind of strange
103 2017-05-11T09:06:27  <wumpus> sorry I meant on outgoing connections, incoming wouldn't make sense as the peer already found you :)
104 2017-05-11T09:06:58  <jonasschnelli> wumpus: Ah... right..
105 2017-05-11T09:07:48  <wumpus> so when your peer connects to someone else, it learns its own address (through the peer's version message), it starts advertizing that
106 2017-05-11T09:08:31  <jonasschnelli> Though, if I start two peers (A,B) and connect_nodes_bi(A.B), then connect with a mininode (C) to B, I guess B should relay addr(A) when I send a getaddr
107 2017-05-11T09:09:55  <wumpus> yes I think so, it should gossip about addresses it knows, though it's heavily randomized
108 2017-05-11T09:15:58  <sipa> eventually, yes
109 2017-05-11T09:16:03  <sipa> but that may take hours
110 2017-05-11T09:16:51  <jonasschnelli> sipa: do you see a better/simpler way how to test if a peer has relayed a addr (through our test/functional/ framework)?
111 2017-05-11T09:17:02  *** d9b4bef9 has quit IRC
112 2017-05-11T09:17:06  *** laurentmt has joined #bitcoin-core-dev
113 2017-05-11T09:17:42  <jonasschnelli> (examine peers.dat is probably a very bad idea)
114 2017-05-11T09:17:55  *** laurentmt has quit IRC
115 2017-05-11T09:18:19  *** d9b4bef9 has joined #bitcoin-core-dev
116 2017-05-11T09:18:27  <wumpus> parsing peers.dat from the test framework seems painful
117 2017-05-11T09:19:05  <jonasschnelli> If there would be a way to retrieve addrmans content from the outside..
118 2017-05-11T09:19:08  <wumpus> also it's not really an interface to be tested, the peers.dat format should be flexible
119 2017-05-11T09:19:16  <jonasschnelli> yeah.. indeed
120 2017-05-11T09:19:22  <wumpus> agreed
121 2017-05-11T09:19:41  <wumpus> some testing-only RPC?
122 2017-05-11T09:20:11  <warren> why testing only?
123 2017-05-11T09:20:15  <wumpus> that part of the code needs to be more testable
124 2017-05-11T09:20:26  <wumpus> so we can assure that it works and track regressions
125 2017-05-11T09:20:49  <wumpus> I don't see much point in having it as documented outside interface, but if you have use cases, sure...
126 2017-05-11T09:21:04  <jonasschnelli> wumpus: Yes. Thought the same... I try to add an debug RPC to outputs addrmans content
127 2017-05-11T09:21:08  <warren> I mean, it would be useful to be able to dump what it thinks it knows about peers during runtime of an ordinary node.
128 2017-05-11T09:31:16  <sipa> we could add an rpc to report all of addrman's db through json?
129 2017-05-11T09:32:54  *** dcousens has quit IRC
130 2017-05-11T09:34:13  *** goksinen has joined #bitcoin-core-dev
131 2017-05-11T09:36:32  *** paveljanik has joined #bitcoin-core-dev
132 2017-05-11T09:36:33  *** paveljanik has joined #bitcoin-core-dev
133 2017-05-11T09:39:02  *** goksinen has quit IRC
134 2017-05-11T09:56:01  *** i3-c3 has quit IRC
135 2017-05-11T10:03:52  *** EagleTM has quit IRC
136 2017-05-11T10:26:32  *** shockoo has quit IRC
137 2017-05-11T10:47:42  <wumpus> yes, exactly
138 2017-05-11T11:03:20  <kallewoof> Heh. I always thought getpeerinfo did just that.
139 2017-05-11T11:03:44  <kallewoof> But I guess addrman can have entries for nodes you aren't currently connected to..
140 2017-05-11T11:04:07  *** rubensayshi has quit IRC
141 2017-05-11T11:04:22  *** rubensayshi has joined #bitcoin-core-dev
142 2017-05-11T11:04:41  <wumpus> right, getpeerinfo shows the peers that the node is currently connected to, not the ones it knows about
143 2017-05-11T11:06:26  *** Giszmo has quit IRC
144 2017-05-11T11:07:16  *** Giszmo has joined #bitcoin-core-dev
145 2017-05-11T11:28:35  *** SopaXorzTaker has joined #bitcoin-core-dev
146 2017-05-11T11:29:26  <jonasschnelli> A simpler approach would be to ensure we directly answer a getaddr request when the debug GetArg("-getaddr_direct") is set
147 2017-05-11T11:30:31  *** laurentmt has joined #bitcoin-core-dev
148 2017-05-11T11:33:43  *** laurentmt has quit IRC
149 2017-05-11T11:34:15  *** laurentmt has joined #bitcoin-core-dev
150 2017-05-11T11:34:57  *** goksinen has joined #bitcoin-core-dev
151 2017-05-11T11:37:10  *** Sosumi has joined #bitcoin-core-dev
152 2017-05-11T11:39:22  *** goksinen has quit IRC
153 2017-05-11T11:46:42  *** Giszmo has quit IRC
154 2017-05-11T11:48:05  *** harrymm has quit IRC
155 2017-05-11T11:58:19  *** Dyaheon has quit IRC
156 2017-05-11T11:59:42  *** Dyaheon has joined #bitcoin-core-dev
157 2017-05-11T12:02:36  *** waxwing has quit IRC
158 2017-05-11T12:02:42  <jonasschnelli> The whole address relay is pretty hard to test on localhost. If 127.0.0.1 then IsRoutable() == false, GetLocalAddress() does not allow 127.0.0.1,..
159 2017-05-11T12:07:56  *** harrymm has joined #bitcoin-core-dev
160 2017-05-11T12:29:11  *** Victorsueca has joined #bitcoin-core-dev
161 2017-05-11T12:37:14  *** waxwing has joined #bitcoin-core-dev
162 2017-05-11T12:45:50  <paveljanik> jonasschnelli, can you please rebase #9697 to make it easier for testing? Thank you.
163 2017-05-11T12:45:52  <gribble> https://github.com/bitcoin/bitcoin/issues/9697 | [Qt] simple fee bumper with user verification by jonasschnelli · Pull Request #9697 · bitcoin/bitcoin · GitHub
164 2017-05-11T12:46:42  <jonasschnelli> paveljanik: I did fresh compile it on Ubuntu 14.10 and didn't had any problems... There is already an ACK on the PR... but I can rebase if it's unavoidable.
165 2017-05-11T12:47:37  <paveljanik> jonasschnelli, ok, np.
166 2017-05-11T12:48:02  <paveljanik> there are three new commits anyway...
167 2017-05-11T12:48:13  <jonasschnelli> Yeah.. right. Let me rebase then.
168 2017-05-11T12:48:33  <jonasschnelli> Give me some minutes (working branch is different right now)
169 2017-05-11T12:49:14  <paveljanik> It is an issue with my workflow... rebase will make it much easier for me (I'll be able to use the default/automated workflow).
170 2017-05-11T12:49:21  *** JackH has quit IRC
171 2017-05-11T12:49:23  <jonasschnelli> sure... will do
172 2017-05-11T12:55:31  *** riemann has joined #bitcoin-core-dev
173 2017-05-11T12:57:49  *** spinza has quit IRC
174 2017-05-11T13:02:08  *** kcud_dab has quit IRC
175 2017-05-11T13:03:52  *** bad_duck has joined #bitcoin-core-dev
176 2017-05-11T13:06:21  *** goksinen has joined #bitcoin-core-dev
177 2017-05-11T13:10:55  *** Giszmo has joined #bitcoin-core-dev
178 2017-05-11T13:11:11  *** goksinen has quit IRC
179 2017-05-11T13:19:59  *** laurentmt has quit IRC
180 2017-05-11T13:27:38  <jonasschnelli> paveljanik: #9697 is now rebased
181 2017-05-11T13:27:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9697 | [Qt] simple fee bumper with user verification by jonasschnelli · Pull Request #9697 · bitcoin/bitcoin · GitHub
182 2017-05-11T13:28:18  *** spinza has joined #bitcoin-core-dev
183 2017-05-11T13:38:22  *** Guyver2 has joined #bitcoin-core-dev
184 2017-05-11T13:40:14  *** goksinen has joined #bitcoin-core-dev
185 2017-05-11T13:44:54  *** goksinen has quit IRC
186 2017-05-11T13:47:27  *** goksinen has joined #bitcoin-core-dev
187 2017-05-11T13:49:38  *** drizztbsd has joined #bitcoin-core-dev
188 2017-05-11T13:50:26  *** d_t has joined #bitcoin-core-dev
189 2017-05-11T13:51:58  *** timothy has quit IRC
190 2017-05-11T13:52:05  *** goksinen has quit IRC
191 2017-05-11T13:54:29  *** goksinen has joined #bitcoin-core-dev
192 2017-05-11T13:55:17  *** d_t has quit IRC
193 2017-05-11T13:58:41  *** drizztbsd is now known as timothy
194 2017-05-11T14:00:40  *** waxwing has quit IRC
195 2017-05-11T14:00:48  *** goksinen has quit IRC
196 2017-05-11T14:20:11  *** goksinen has joined #bitcoin-core-dev
197 2017-05-11T14:20:40  *** zooko has joined #bitcoin-core-dev
198 2017-05-11T14:22:51  *** zooko has left #bitcoin-core-dev
199 2017-05-11T14:23:31  *** zooko has joined #bitcoin-core-dev
200 2017-05-11T14:23:53  *** zooko_ has joined #bitcoin-core-dev
201 2017-05-11T14:24:04  *** zooko has quit IRC
202 2017-05-11T14:24:08  *** zooko_ has quit IRC
203 2017-05-11T14:24:21  *** SopaXorzTaker has quit IRC
204 2017-05-11T14:24:36  *** zooko has joined #bitcoin-core-dev
205 2017-05-11T14:24:56  *** goksinen has quit IRC
206 2017-05-11T14:24:58  *** SopaXorzTaker has joined #bitcoin-core-dev
207 2017-05-11T14:26:50  *** goksinen has joined #bitcoin-core-dev
208 2017-05-11T14:32:48  *** d_t has joined #bitcoin-core-dev
209 2017-05-11T14:32:56  *** wallet42 has quit IRC
210 2017-05-11T14:33:19  *** wallet42 has joined #bitcoin-core-dev
211 2017-05-11T14:38:13  *** d_t has quit IRC
212 2017-05-11T14:44:31  *** waxwing has joined #bitcoin-core-dev
213 2017-05-11T14:47:04  *** Cheeseo has joined #bitcoin-core-dev
214 2017-05-11T14:52:31  *** JackH has joined #bitcoin-core-dev
215 2017-05-11T14:59:26  *** zooko has quit IRC
216 2017-05-11T15:00:18  *** Cheeseo has quit IRC
217 2017-05-11T15:03:02  *** riemann has quit IRC
218 2017-05-11T15:04:16  *** Dyaheon has quit IRC
219 2017-05-11T15:04:57  *** Dyaheon has joined #bitcoin-core-dev
220 2017-05-11T15:09:02  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10387: [WIP] Define and signal NODE_NETWORK_LIMITED (pruned peers) (master...2017/05/node_network_limited) https://github.com/bitcoin/bitcoin/pull/10387
221 2017-05-11T15:45:57  *** abpa has joined #bitcoin-core-dev
222 2017-05-11T15:50:20  *** waxwing has quit IRC
223 2017-05-11T15:55:13  *** SopaXorzTaker has quit IRC
224 2017-05-11T16:03:48  *** waxwing has joined #bitcoin-core-dev
225 2017-05-11T16:10:19  *** timothy has quit IRC
226 2017-05-11T16:12:07  *** goksinen has quit IRC
227 2017-05-11T16:23:00  *** gm2051 has quit IRC
228 2017-05-11T16:26:47  *** gm2051 has joined #bitcoin-core-dev
229 2017-05-11T16:29:58  *** harrymm has quit IRC
230 2017-05-11T16:32:18  *** harrymm has joined #bitcoin-core-dev
231 2017-05-11T16:52:33  *** talmai has joined #bitcoin-core-dev
232 2017-05-11T16:56:02  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/7f2b9e0868f5...79aeff6e08f3
233 2017-05-11T16:56:03  <bitcoin-git> bitcoin/master 9970219 Matt Corallo: Update contrib/debian to latest Ubuntu PPA upload....
234 2017-05-11T16:56:03  <bitcoin-git> bitcoin/master a8e9286 Matt Corallo: Bump minimum boost version in contrib/debian
235 2017-05-11T16:56:04  <bitcoin-git> bitcoin/master c5071e1 Matt Corallo: Build with QT5 on Debian-based systems using contrib/debian
236 2017-05-11T16:56:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10328: Update contrib/debian to latest Ubuntu PPA upload. (master...2017-05-update-debian) https://github.com/bitcoin/bitcoin/pull/10328
237 2017-05-11T17:07:28  *** talmai has quit IRC
238 2017-05-11T17:08:51  *** talmai has joined #bitcoin-core-dev
239 2017-05-11T17:14:35  *** goksinen has joined #bitcoin-core-dev
240 2017-05-11T17:20:03  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79aeff6e08f3...18c9debe602d
241 2017-05-11T17:20:04  <bitcoin-git> bitcoin/master a637734 Luke Dashjr: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str
242 2017-05-11T17:20:04  <bitcoin-git> bitcoin/master 18c9deb Wladimir J. van der Laan: Merge #10341: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str...
243 2017-05-11T17:20:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10341: rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str (master...rpcwallet_uv_workaround) https://github.com/bitcoin/bitcoin/pull/10341
244 2017-05-11T17:27:37  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/18c9debe602d...eb8263bdc9d3
245 2017-05-11T17:27:37  <bitcoin-git> bitcoin/master 0c60c63 practicalswift: Remove unused Python imports
246 2017-05-11T17:27:38  <bitcoin-git> bitcoin/master eb8263b Wladimir J. van der Laan: Merge #10317: Remove unused Python imports...
247 2017-05-11T17:28:06  <bitcoin-git> [bitcoin] laanwj closed pull request #10317: Remove unused Python imports (master...remove-unused-python-imports-ii) https://github.com/bitcoin/bitcoin/pull/10317
248 2017-05-11T17:57:19  *** dermoth has quit IRC
249 2017-05-11T17:58:06  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb8263bdc9d3...94e52273f30f
250 2017-05-11T17:58:06  <bitcoin-git> bitcoin/master 6c914ac Thomas Snider: [wallet] Securely erase potentially sensitive keys/values
251 2017-05-11T17:58:07  <bitcoin-git> bitcoin/master 94e5227 Wladimir J. van der Laan: Merge #10308: [wallet] Securely erase potentially sensitive keys/values...
252 2017-05-11T17:58:36  <bitcoin-git> [bitcoin] laanwj closed pull request #10308: [wallet] Securely erase potentially sensitive keys/values (master...tjps_secure_erase) https://github.com/bitcoin/bitcoin/pull/10308
253 2017-05-11T18:03:48  *** dermoth has joined #bitcoin-core-dev
254 2017-05-11T18:05:08  *** molz_ has joined #bitcoin-core-dev
255 2017-05-11T18:07:57  *** mol has quit IRC
256 2017-05-11T18:18:03  *** jcliff42 has joined #bitcoin-core-dev
257 2017-05-11T18:20:25  <bitcoin-git> [bitcoin] morcos opened pull request #10388: Output line to debug.log when IsInitialBlockDownload latches to false (master...printIBD) https://github.com/bitcoin/bitcoin/pull/10388
258 2017-05-11T18:29:35  <jonasschnelli> gmaxwell: The idea behind the signaling 7056 blocks in NODE_NETWORK_LIMITED was, that SPV peers and other very irregular network participants can catch up filtered (or non filtered) blocks of about a month.
259 2017-05-11T18:30:40  <jonasschnelli> Though the value itself is questionable (I though NODE_NETWORK_LIMITED_HIGH^2 may be resonable).
260 2017-05-11T18:32:01  *** jcliff42 has quit IRC
261 2017-05-11T18:32:53  *** jcliff42 has joined #bitcoin-core-dev
262 2017-05-11T18:33:22  <gmaxwell> I'm pretty doubtful people are going to set pruning to anything but not at all or all the way right now.
263 2017-05-11T18:38:01  <jonasschnelli> gmaxwell: I don't know. I personally would consider pruning to 10GB or something that doesn't hurt. But yeah.... I see the point with UTXO syncs and maybe reserve it then for future use cases (though we could also add another bit)
264 2017-05-11T18:38:47  *** jcliff42 has quit IRC
265 2017-05-11T18:39:36  <morcos> gmaxwell: given the size requirements for other aspects of the data directory (such as chainstate), it seems to me its not unreasonable to keep several gigs of blocks...  I think if there was a 10GB option, it might be heavily used, especially if it was either recommended or somehow the default
266 2017-05-11T18:40:37  *** molz_ has quit IRC
267 2017-05-11T18:41:20  *** moli_ has joined #bitcoin-core-dev
268 2017-05-11T18:42:57  *** dermoth has quit IRC
269 2017-05-11T18:43:03  <instagibbs> Defaults are obviously quite sticky. In my experience almost no one even knows about pruning.
270 2017-05-11T18:43:33  <instagibbs> (so people just shut if off)
271 2017-05-11T18:44:25  <jonasschnelli> Also consider the use case (thats getting more and more popular) where people link their SPV wallets with their full node. There a "month of blocks" could make sense...
272 2017-05-11T18:44:38  <jonasschnelli> And I'm not saying this is a good use case... :)
273 2017-05-11T18:47:59  <jonasschnelli> instagibbs: Some people told me that the prices per GB storage falls after moors law, but I personally feel that it was much simpler to run a full node back in 2013,... and not at least because of the disk requirement.
274 2017-05-11T18:49:28  *** protomar has joined #bitcoin-core-dev
275 2017-05-11T18:49:38  <instagibbs> Most people buying computers aren't optimizing for 100GB+ chain sizes.
276 2017-05-11T18:50:56  <wumpus> "Some people told me that the prices per GB storage falls after moors law", indeed, that hasn't been true for quite a while
277 2017-05-11T18:51:26  <gmaxwell> The setting based on size thing really doesn't work that well, the two logical settings are unpruned and the minimum.
278 2017-05-11T18:52:06  <gmaxwell> so I'm not saying that keeping X or Y is useless, but we need a different interface to make them ever used.
279 2017-05-11T18:52:41  <gmaxwell> And the big difference is "can people sync from you" -- p2p spv nodes are almost non-existant these days.
280 2017-05-11T18:52:43  <wumpus> there is currently no reason to select anything but the minimum if you set up pruning
281 2017-05-11T18:53:11  <wumpus> if it did serve the latter blocks I'd gladly set the pruning to larger, and I've heard similar things from other people, but there's just no reason now
282 2017-05-11T18:53:31  *** jcliff42 has joined #bitcoin-core-dev
283 2017-05-11T18:54:19  <gmaxwell> The context here though is having yet another level.
284 2017-05-11T18:54:21  *** jcliff42 has joined #bitcoin-core-dev
285 2017-05-11T18:54:55  <murchandamus> Howdy
286 2017-05-11T18:55:14  <gmaxwell> I don't think having three levels of just pruning makes a lot of sense (nor do I think it's supported by the fetching data we have), when also there will be proposals for start-from-utxo-assumevalid which will have its own levels of storage.
287 2017-05-11T18:55:33  <jonasschnelli> Right, the question is if both NODE_NETWORK_LIMITED_(LOW|HIGH) is enabled, should we then use a third, larger value (bit 1: 144, bit 2: 1008, both bits: ?)
288 2017-05-11T18:55:54  <sipa> we could leave it undefined for now
289 2017-05-11T18:56:04  <wumpus> on the other hand if there are three possibiilties with those bits, it makes sense to give the combination meaning too
290 2017-05-11T18:56:13  <wumpus> or leave it explicitly undefined for future expansion,s ure
291 2017-05-11T18:56:28  <sipa> merely the presence of having server-but-not-full-archival nodes will likely change things already
292 2017-05-11T18:56:31  <gmaxwell> What I suggested was that it's undefined for setting, but for recieving you know it means at least X blocks, but it may also require other things, so you can't set it yet.
293 2017-05-11T18:56:32  <sipa> and we'll learn from that
294 2017-05-11T18:56:35  *** dermoth has joined #bitcoin-core-dev
295 2017-05-11T18:56:38  <jonasschnelli> Yes. It felt after a waste if we don't define it. Well, undefined (for future usecases) is also a definition.
296 2017-05-11T18:56:56  <wumpus> agree
297 2017-05-11T18:57:00  <instagibbs> gmaxwell, s/setting/sending/?
298 2017-05-11T18:57:13  <gmaxwell> instagibbs: both.
299 2017-05-11T18:57:24  <wumpus> gmaxwell: yes "it means at least..." makes a lot of sense for backwards compatibility
300 2017-05-11T18:58:05  <gmaxwell> If you see both bits set, then it means they have at least 2016*2 blocks (which is what I suggested). But you don't set it yet, because it may (will) later be defined to say "And I offer a UTXO syncpoint" or whatnot.
301 2017-05-11T18:58:19  <wumpus> yes
302 2017-05-11T18:58:27  *** jcliff42 has quit IRC
303 2017-05-11T18:58:31  <gmaxwell> to be extra conservative it could just be defined to mean at least _HIGH  now. I don't have a strong opinion.
304 2017-05-11T18:58:38  <gmaxwell> you can always increase the requirement later.
305 2017-05-11T18:59:17  *** SopaXorzTaker has joined #bitcoin-core-dev
306 2017-05-11T19:00:16  <wumpus> #startmeeting
307 2017-05-11T19:00:16  <lightningbot> Meeting started Thu May 11 19:00:16 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
308 2017-05-11T19:00:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
309 2017-05-11T19:00:26  <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
310 2017-05-11T19:00:31  <sipa> present
311 2017-05-11T19:00:40  <murchandamus> present
312 2017-05-11T19:00:44  <wumpus> topics?
313 2017-05-11T19:00:49  <sipa> murchandamus == murch?
314 2017-05-11T19:00:51  <cfields> hi, here
315 2017-05-11T19:00:54  <instagibbs> yes sipa
316 2017-05-11T19:00:54  <murchandamus> aye!
317 2017-05-11T19:00:56  <morcos> gmaxwell: oh ok, i agree with not defining now..  maybe we should make just _HIGH more then though
318 2017-05-11T19:00:59  <kanzure> hi.
319 2017-05-11T19:01:36  <gmaxwell> morcos: yes, I was thinking HIGH would be targeted at hosts syncing 2016 blocks, but I forget where the breakpoints were exactly in sipas' data.
320 2017-05-11T19:01:39  <wumpus> any proposed topics? (we can continue the pruning service bits topic if people want that)
321 2017-05-11T19:01:40  <BlueMatt> damnit, can enver remember topics i wanted to bring up come meeting time :(
322 2017-05-11T19:01:57  <luke-jr> O.o?
323 2017-05-11T19:02:18  <gmaxwell> wumpus: well we should talk about per-txo. I think it's ready for merge except for more testing/review.
324 2017-05-11T19:02:26  <instagibbs> suggested topic: fee targeting/coin selection overhaul
325 2017-05-11T19:02:35  <wumpus> #topic per-txo utxo database
326 2017-05-11T19:02:52  <sipa> #10148
327 2017-05-11T19:02:54  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
328 2017-05-11T19:02:56  <gmaxwell> if people haven't seen the graphs: https://cloud.githubusercontent.com/assets/548488/25769030/c84fe65e-31c4-11e7-8819-264c44e50ddf.png
329 2017-05-11T19:03:02  <sipa> oops, no, #10195
330 2017-05-11T19:03:04  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
331 2017-05-11T19:03:12  <morcos> sorry sipa, that has been on my list, but my list has been gathering dust for the last couple weeks
332 2017-05-11T19:03:13  <BlueMatt> I'm still halfway through review
333 2017-05-11T19:03:16  <gmaxwell> The graphs should be making all your mouths water.
334 2017-05-11T19:03:30  <instagibbs> why is y-axis in block time :P
335 2017-05-11T19:03:34  <wumpus> ah yes I was still testing #10148, should probably switch to #10195
336 2017-05-11T19:03:37  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
337 2017-05-11T19:03:39  <instagibbs> clock*
338 2017-05-11T19:03:39  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
339 2017-05-11T19:03:41  <gmaxwell> instagibbs: so that the flushing graph works out.
340 2017-05-11T19:03:52  <sipa> instagibbs: so that the x axis of both graphs lines up
341 2017-05-11T19:04:00  <cfields> i've made it through review, but I lack enough confidence to ACK the thing :\
342 2017-05-11T19:04:04  <BlueMatt> gm2051: #10192
343 2017-05-11T19:04:05  <gmaxwell> The most impressive thing about that chart isn't the ~33% speedup, it's the reduction in flushing frequency.
344 2017-05-11T19:04:08  <gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
345 2017-05-11T19:04:17  <BlueMatt> gmaxwell: ^
346 2017-05-11T19:04:20  <cfields> gmaxwell: yes, that's great.
347 2017-05-11T19:04:33  <sipa> i was very surprised by how much it reduces flushing
348 2017-05-11T19:04:41  *** jcliff42 has joined #bitcoin-core-dev
349 2017-05-11T19:04:49  <wumpus> nice chart
350 2017-05-11T19:04:54  <sipa> my guess is that the resulting speedup isn't that dramatic because it's running on a system with pretty fast I/O
351 2017-05-11T19:05:12  <wumpus> heh, but most users have systems with slow i/o
352 2017-05-11T19:05:27  <sipa> oh, one downside: chainstate db goes from 2.2G to 2.7G
353 2017-05-11T19:05:30  <gmaxwell> right, testing it on a system with slow i/o would be interesting. But will take forever.
354 2017-05-11T19:05:45  <BlueMatt> 2.7 seems fine
355 2017-05-11T19:06:09  <luke-jr> hmm
356 2017-05-11T19:06:31  <sipa> the TODOs that i know of are a few code cleanups (marked as TODO in the code), and better UI wrt the upgrade process
357 2017-05-11T19:06:45  <sipa> there is a one-time upgrade of the old db to the new db at startup, which can be interrupted
358 2017-05-11T19:06:55  <gmaxwell> The upgrade doesn't take long on a system with fast IO at least.
359 2017-05-11T19:06:57  <BlueMatt> sipa: it needs way more review
360 2017-05-11T19:07:02  <sipa> BlueMatt: of course
361 2017-05-11T19:07:03  <BlueMatt> there are lots of things in that queue, sadly
362 2017-05-11T19:07:10  <wumpus> upgrade should be fast if it just iterates through the db in sorted order
363 2017-05-11T19:07:18  <wumpus> even on systems with fairly slow (seek) i/o
364 2017-05-11T19:07:28  <sipa> wumpus: it does, it takes a couple of minutes on a system with fast I/O
365 2017-05-11T19:08:02  <wumpus> I'll try it out this week
366 2017-05-11T19:08:36  <gmaxwell> One thing to keep in mind is that keeping it unmerged reduces testing. Absolutely it needs more review before being merged, but we also should try to get it merged sooner rather than later.
367 2017-05-11T19:08:46  <gmaxwell> So that we get more time baking on it in master.
368 2017-05-11T19:08:56  *** jcliff42 has quit IRC
369 2017-05-11T19:09:00  <BlueMatt> gmaxwell: we're not even close to that point
370 2017-05-11T19:09:12  <BlueMatt> but, yes, we should be agressive about merge, as long as its a ways before release
371 2017-05-11T19:09:14  <morcos> agreed gmaxwell, same thing with #10199
372 2017-05-11T19:09:16  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
373 2017-05-11T19:09:28  <sipa> morcos: i'll do another review pass on that today
374 2017-05-11T19:09:40  <wumpus> yes, this shouldn't be something to merge last minute for 0.15
375 2017-05-11T19:09:44  <morcos> good thing about that one, is its a lot less likely to casue a disaster
376 2017-05-11T19:09:45  * BlueMatt finds 10199 to be wayyyy more important than per-utxo
377 2017-05-11T19:09:50  *** kexkey has joined #bitcoin-core-dev
378 2017-05-11T19:09:55  * morcos disagrees
379 2017-05-11T19:10:13  <gmaxwell> I strongly disagree.
380 2017-05-11T19:10:44  <wumpus> they're both important for different reasons
381 2017-05-11T19:10:55  <wumpus> it's comparing apples and oranges
382 2017-05-11T19:11:05  *** mol has joined #bitcoin-core-dev
383 2017-05-11T19:11:09  <BlueMatt> anyway, do we have any real topics?
384 2017-05-11T19:11:29  <sipa> i have one low-priority idea i'd like to talk about (running utxo commitments)
385 2017-05-11T19:11:31  * BlueMatt wishes the ny weather were better...
386 2017-05-11T19:11:36  <BlueMatt> sipa: shoot
387 2017-05-11T19:11:46  <wumpus> #topic fee targeting/coin selection overhaul (instagibbs)
388 2017-05-11T19:11:47  <gmaxwell> BlueMatt: it's beautiful here in mountain view today.
389 2017-05-11T19:12:06  <sipa> instagibbs: topic
390 2017-05-11T19:12:17  <murchandamus> gmaxwell: A bit cloudy here in Palo Alto though. ;)
391 2017-05-11T19:12:24  <instagibbs> So I tried my hand at doing redoing fee targeting #10360 without directly changing coin selection
392 2017-05-11T19:12:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10360 | [WIP] [Wallet] Target effective value during transaction creation by instagibbs · Pull Request #10360 · bitcoin/bitcoin · GitHub
393 2017-05-11T19:12:36  <instagibbs> Was wondering if people were wary of that, versus a complete overhaul
394 2017-05-11T19:12:43  <instagibbs> morcos has concerns
395 2017-05-11T19:12:49  <morcos> wary is a good word for it
396 2017-05-11T19:12:55  <morcos> not opposed
397 2017-05-11T19:13:02  <gmaxwell> I feel a little uneasy about the changes to augment selection while we don't have a strategy to sweep dust. It worries me that we're potentially going to again untintentionally create another UTXO count blowup event.
398 2017-05-11T19:13:11  <sipa> instagibbs: i haven't looked into the details... is it just treating the net value of its output as amount - feerate*size_of_spend ?
399 2017-05-11T19:13:15  <murchandamus> I've talked a bit with instagibbs about it and it seems to me that when that approach finds a direct match it may have a huge number of inputs
400 2017-05-11T19:13:20  <instagibbs> sipa yes
401 2017-05-11T19:13:36  <gmaxwell> murchandamus: that sounds great to me. :P
402 2017-05-11T19:13:43  <murchandamus> I've combined a similar approach but trying to combine inputs by size large to small
403 2017-05-11T19:14:01  *** moli_ has quit IRC
404 2017-05-11T19:14:05  <instagibbs> sipa, so you may get more smaller inputs that directly match, for example
405 2017-05-11T19:14:13  <murchandamus> gmaxwell: I think that slightly bigger average transaction with lower variance in transaction size are better than huge variance in transaction size
406 2017-05-11T19:14:39  <morcos> i like the idea of being at least somewhat fee smart, and including more inputs when fees are lower
407 2017-05-11T19:14:41  <sipa> but even if it spends many inputs, it always does so in a way that is economical
408 2017-05-11T19:14:57  <instagibbs> sipa, it will always use "positive effective value" inputs
409 2017-05-11T19:14:59  <sipa> so unless you assume that the feerate is going down in the future, there is little reason to postpone spending them
410 2017-05-11T19:15:05  <murchandamus> morcos: Exactly. We have huge variance in fees over the week
411 2017-05-11T19:15:10  <gmaxwell> murchandamus: high to low sounds like it would destroy privacy.
412 2017-05-11T19:15:10  <morcos> the idea of wanting to do a quick transaction and paying 200 sat/byte to do it, and you include tons of little inputs that have little to none net value seems bad to me
413 2017-05-11T19:15:46  <murchandamus> sipa: But adding a single input costs as much as four outputs, so you'd probably rather add a change output when fees are high than add another input, and later in the week do a few consolidation transactions
414 2017-05-11T19:15:55  * luke-jr wonders how contentious it would be to move to a system where dust requires a larger proof so it can be pruned from the UTXO set
415 2017-05-11T19:16:05  <murchandamus> I've been hearing that some people do this to save money
416 2017-05-11T19:16:07  <gmaxwell> morcos: I though about that and I think a nice estimate would be the ratio between the current feerate set and the BIG_NUM target (e.g. 1008 block target).  If this ratio is low, then you should be agressive in spending.
417 2017-05-11T19:16:11  <morcos> admittedly its a difficult problem...  how do you distinguish a user that only does 200 sat/byte txs vs one that has a range
418 2017-05-11T19:16:32  <murchandamus> gmaxwell: I don't think it does, because it's only the selection for making exact matches
419 2017-05-11T19:16:43  <morcos> gmaxwell: yes, i agree... something like that
420 2017-05-11T19:16:46  <murchandamus> and you don't know if the first combination that matched was actually among the largest in your wallet
421 2017-05-11T19:16:58  *** Cheeseo has joined #bitcoin-core-dev
422 2017-05-11T19:16:58  *** Cheeseo has joined #bitcoin-core-dev
423 2017-05-11T19:17:22  <morcos> anyway, clearly there are a lot of ideas here, and i kidn of think that the amount of consideration that has to go into most changes is almost the same, and it might not be worthing doing all of that sanity checking if we're only making a small change
424 2017-05-11T19:17:23  <instagibbs> yes, so there are plenty of interesting strategies, the question is should we not be making semi-obvious fixing until we can agree on those :)
425 2017-05-11T19:17:34  <murchandamus> gmaxwell: interesting approach
426 2017-05-11T19:18:22  <instagibbs> related: can we kill minimum total fee?
427 2017-05-11T19:18:22  <morcos> at the very least, i'd think this should be lower priority for 0.15 than the prevously mentioned things right now... so we have to think about resources
428 2017-05-11T19:18:33  <morcos> instagibbs: +1 on that for a first step
429 2017-05-11T19:18:37  <sipa> instagibbs: ack
430 2017-05-11T19:18:38  <instagibbs> morcos, yes that was the feeling I get
431 2017-05-11T19:18:41  <murchandamus> instagibbs: Accounting for UTXO in selection by effective value does take a load of pain out of selection strategies
432 2017-05-11T19:19:21  <gmaxwell> instagibbs: but if a 'semi obvious fix' blows up other considerations thats bad.  Do you have a reason to believe your change won't cause a massive increase in utxo accumulation?
433 2017-05-11T19:19:33  <morcos> also i have a PR #9343 that also removes edge case logic.  cleaning these things up now will make future improvements easier to do and reason about
434 2017-05-11T19:19:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | Dont create change at dust limit by morcos · Pull Request #9343 · bitcoin/bitcoin · GitHub
435 2017-05-11T19:19:38  <murchandamus> instagibbs: I'm not sure that just this change with the current selection strategy of Core does much better in the selection, because of the selecting/deselecting pass
436 2017-05-11T19:19:43  <instagibbs> gmaxwell, no, I wasn't assuming as much, sorry if that seemed implied
437 2017-05-11T19:20:09  <murchandamus> gmaxwell: Pretty sure it would rather decrease UTXO footprints
438 2017-05-11T19:20:36  <murchandamus> right now Core will often fail in the first few passes when it selects more inputs because it hadn't accounted for the fees in advance
439 2017-05-11T19:20:37  <sipa> instagibbs: which feerate are you using?
440 2017-05-11T19:20:57  <instagibbs> sipa, whatever the user has selected via settings
441 2017-05-11T19:21:01  <gmaxwell> instagibbs: well, thats why I ask. basically, in any mature system you can have 'bugs' which you depend on. at first glance it semeed to me that your PR might fix a bug where we're overly agressively spending TXO that are negative value. But we may depend on that bug to help manage the UTXO size.  At least that was my impression.
442 2017-05-11T19:21:05  <murchandamus> with this change it would always succeed as soon as it finds an exact match
443 2017-05-11T19:21:08  <sipa> instagibbs: oh, duh
444 2017-05-11T19:21:09  <instagibbs> well, aside from total minimum fee, because that's stupid
445 2017-05-11T19:21:55  <instagibbs> gmaxwell, could be. Maybe next step, aside from general refactor and cleaning, is to get better data
446 2017-05-11T19:22:08  <gmaxwell> murchandamus: I'm not following your logic. Yes, the first few passes will fail, then it will target a higher amount, and be successful.
447 2017-05-11T19:22:18  <murchandamus> gmaxwell: Yes, it shoudl never select UTXO that are negative effective value
448 2017-05-11T19:22:22  <instagibbs> and stop throwing away money as fees egregiously: #10333
449 2017-05-11T19:22:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
450 2017-05-11T19:22:35  <gmaxwell> murchandamus: By "should" do you mean the current behavior?
451 2017-05-11T19:22:43  <instagibbs> current behavior almost certainly does
452 2017-05-11T19:22:49  <gmaxwell> The current behavior absolutely will select txos with negative value.
453 2017-05-11T19:23:02  <sipa> So how about we fix that first?
454 2017-05-11T19:23:06  <gmaxwell> And "fixing" that may have severely deletarious effects on the network.
455 2017-05-11T19:23:08  <murchandamus> gmaxwell: It only fails if it doesn't find a transaction input set within the number of estimated inputs from the previous tries
456 2017-05-11T19:23:11  <morcos> sipa: yeah i was thinking that
457 2017-05-11T19:23:12  <instagibbs> I could always just make it ignore negative effective value
458 2017-05-11T19:23:13  <morcos> gmaxwell: disagree
459 2017-05-11T19:23:13  <instagibbs> ...
460 2017-05-11T19:23:14  <instagibbs> lol
461 2017-05-11T19:23:38  <instagibbs> I mean either it's a feature, and we shouldnt fix it, or a bug and we should
462 2017-05-11T19:23:46  <morcos> instagibbs: yeah exactly
463 2017-05-11T19:24:09  <gmaxwell> It can be both! :)
464 2017-05-11T19:24:18  <murchandamus> gmaxwell: I meant "should" as in when you calculate the effective value of a UTXO, if it is a negative effective value it shouldn't be selected
465 2017-05-11T19:24:28  <instagibbs> aspirational should?
466 2017-05-11T19:24:29  <sdaftuar> so there's a difference here between generally factoring in feerates in the coin selection, and throwing out inputs that have negative value.  i assume that's what we're getting at?
467 2017-05-11T19:24:33  <murchandamus> gmaxwell: actually yes
468 2017-05-11T19:24:37  <gmaxwell> It's a feature when its mild and happening during times of low feerate. And a bug when its severe when it is insane and happening during high feerate.
469 2017-05-11T19:24:42  <murchandamus> current behavior would select them
470 2017-05-11T19:24:48  <instagibbs> gmaxwell, fair enough...
471 2017-05-11T19:25:00  <wumpus> yes, eating utxos with negative value cleans up the utxo set
472 2017-05-11T19:25:06  <morcos> gmaxwell: right now when feerates vary from 10 to 200 sat/byte.   something that is 0 at 200 sat/byte should be cleaned up at a lower fee rate, not thrown away
473 2017-05-11T19:25:26  <gmaxwell> Fixing it unconditionally without doing something about dust cleanup may be quite harmful to the network.
474 2017-05-11T19:25:30  <wumpus> of course it's better to not create them in the first place
475 2017-05-11T19:25:43  <morcos> wumpus: yes!  see #9343
476 2017-05-11T19:25:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | Dont create change at dust limit by morcos · Pull Request #9343 · bitcoin/bitcoin · GitHub
477 2017-05-11T19:25:57  <murchandamus> morcos: That's what I meant
478 2017-05-11T19:25:58  <instagibbs> ^I should review that one
479 2017-05-11T19:25:59  <morcos> i'm not sure thats the only way they are created, perhaps we could do more to avoid creating them also
480 2017-05-11T19:26:12  <gmaxwell> morcos: well they're created by people being buttheads.
481 2017-05-11T19:26:15  <morcos> i should say, i'm sure thats not the only way
482 2017-05-11T19:26:21  <instagibbs> I noticed in current logic we create near-dust, but when we're modifying change, we have much higher bar to clear
483 2017-05-11T19:26:23  <gmaxwell> and no amount of fixing the wallet will prevent their creation.
484 2017-05-11T19:26:24  <instagibbs> we should sync this
485 2017-05-11T19:26:36  <wumpus> yes, we should get that one in
486 2017-05-11T19:26:49  <wumpus> gmaxwell: well not creating them ourselves is not a total solution, but it helps
487 2017-05-11T19:27:01  <gmaxwell> wumpus: absolutely, sorry if it sounded like I said otherwise.
488 2017-05-11T19:27:06  <morcos> gmaxwell: yeah its a good question how many are created unintentionally vs intentionally
489 2017-05-11T19:27:47  <morcos> it wouldn't be unreasonable to raise the limit for intentionally creating them in Core, in adddition to imporving unintentional behavior
490 2017-05-11T19:27:51  *** Firescar96 has joined #bitcoin-core-dev
491 2017-05-11T19:27:53  <gmaxwell> and at least as far as the "some anonymous third party sends you a few bitcents"  I think it's fine to spend those at a slight loss, esp if its in a privacy preserving way, and double especially if it's at as low a fee rate as you expect to see.
492 2017-05-11T19:27:59  <murchandamus> morcos: Core never creates change outputs smaller than 0.01 BTC unless the wallet is being almost depleted with the transaction, right?
493 2017-05-11T19:28:22  <morcos> murchandamus: well.. thats the design goal, i don't think its achieved
494 2017-05-11T19:28:29  <instagibbs> it's not achieved at all
495 2017-05-11T19:28:30  <instagibbs> sad!
496 2017-05-11T19:28:30  <gmaxwell> what morcos said
497 2017-05-11T19:28:44  <gmaxwell> well it's better since 0.13.whatever when we fixed some things.
498 2017-05-11T19:28:53  <gmaxwell> with the target/2 checks.
499 2017-05-11T19:29:04  <murchandamus> I'll have to check out the linked issue
500 2017-05-11T19:29:11  <morcos> in particular, if you have nTotalLower < target + CENT, you aim for target, and almost definitely create some stupidly small change
501 2017-05-11T19:29:26  <morcos> among other posibilities
502 2017-05-11T19:29:37  <murchandamus> morcos: Ah right, I forgot about the pre-selection before knapsack
503 2017-05-11T19:29:39  <morcos> the linked issue is even more edge case
504 2017-05-11T19:29:41  <murchandamus> thanks for the reminder
505 2017-05-11T19:30:07  <morcos> but like nTotalFee needs to go away before its easy to clean up the general case
506 2017-05-11T19:30:22  <morcos> easIER
507 2017-05-11T19:30:40  <murchandamus> morcos: I think the way to go would be to dissect and modularize the coin selection out of wallet.cpp, if that's possible
508 2017-05-11T19:30:44  <murchandamus> right now it is such a moloch
509 2017-05-11T19:31:06  <instagibbs> I mean you can basically just throw away anything at or below SelectCoins, imo
510 2017-05-11T19:31:10  <wumpus> murchandamus: yes please
511 2017-05-11T19:31:27  <gmaxwell> Moloch whose mind is pure machinery!
512 2017-05-11T19:32:16  <murchandamus> I think instagibbs and I might coordinate something there, and jnewberry was also interested AFAIK
513 2017-05-11T19:32:21  <gmaxwell> can we new-subject?  good discussion on this, lots of PRs for people to look at and discuss more. :)
514 2017-05-11T19:32:28  <instagibbs> morcos is also interested
515 2017-05-11T19:32:34  <instagibbs> yes I'm satisfied, we can continue offline
516 2017-05-11T19:32:46  <murchandamus> thanks, me too
517 2017-05-11T19:32:48  <wumpus> #topic running utxo commitments (sipa)
518 2017-05-11T19:32:56  <sipa> ok
519 2017-05-11T19:32:58  <gmaxwell> instagibbs: in any case, that one concern: that we might 'fix' what is dedusting the UTXO is the only reason I didn't ACK your patch. So we should try to get confidence there or add some other fix for that.
520 2017-05-11T19:33:13  <instagibbs> gmaxwell, my firster iteration didnt even "fix" it :P
521 2017-05-11T19:33:17  * jonasschnelli think we should have a graphical 3D "real coins" (in the size of the BTC value) manual drag'n'drop coin selection
522 2017-05-11T19:33:20  <sipa> so, gmaxwell and i have been thinking about the possibility of maintaining a UTXO commitment hash all the time
523 2017-05-11T19:34:03  <sipa> this would be useful for making gettxoutsetinfo instantaneous, or for syncing from someone else's UTXO set, or as the basis for a softfork later
524 2017-05-11T19:34:11  *** Cheeseo has quit IRC
525 2017-05-11T19:34:16  *** Dyaheon has quit IRC
526 2017-05-11T19:34:18  *** Rob has joined #bitcoin-core-dev
527 2017-05-11T19:34:24  <wumpus> yes, that would be useful
528 2017-05-11T19:34:36  <sipa> and it seems it would be possible to have an implementation that does this at a cost of a few microseconds per input and per output
529 2017-05-11T19:34:40  *** Rob is now known as Guest50211
530 2017-05-11T19:34:42  <gmaxwell> A first requirement for any kind of UTXO assumevalid is having a continuous commitment value to simplify review.
531 2017-05-11T19:34:44  <sipa> in a cryptographically secure way
532 2017-05-11T19:35:05  *** Sosumi has quit IRC
533 2017-05-11T19:35:33  <wumpus> jonasschnelli: that's pretty much just "a better GUI for coin control" right?
534 2017-05-11T19:35:39  <gmaxwell> Effectively, we construct an incremental unordered hash for sets-- so you can add and remove entries one at a time... Because just one scheme isn't enough, we actually constructed several, and now have a fun tradeoffs challenge to decide between them.
535 2017-05-11T19:35:41  <sipa> there are a few different possible implementations (one is based on multiplying big numbers mod a big prime, one is based on EC math, one is based on adding large hashes toether)... with different performance and security tradeoffs, i'll send a mail about it to the ML soon
536 2017-05-11T19:36:00  <BlueMatt> ah, ok, was gonna ask what the design was, cool
537 2017-05-11T19:36:07  <instagibbs> i love the alternative explanations...
538 2017-05-11T19:36:19  *** cbits has joined #bitcoin-core-dev
539 2017-05-11T19:36:19  <BlueMatt> i mean we can also not use complicated solutions and be willing to do it in the background at a cost of however many milliseconds later
540 2017-05-11T19:36:29  <BlueMatt> dunno how complicated your proposal is, of course
541 2017-05-11T19:36:59  <sipa> BlueMatt: map every UTXO to either a 3072-bit integer and multiply those for all outputs, or to an EC point and all those for all outputs
542 2017-05-11T19:37:14  <sipa> the multiplication approach is faster, but harder to cache
543 2017-05-11T19:37:18  <gmaxwell> The strength of our proposals is strictly better than the discrete log assumption.  Neighter are especially complex, though the multiplying one is probably simpler for joe-fool to implement as long as they don't care about performance.
544 2017-05-11T19:37:33  <sipa> the EC approach could allow us to cache the effect of a single transaction, and then instantly apply it to the running commitment
545 2017-05-11T19:38:11  *** jonasschnelli is now known as joe-fool
546 2017-05-11T19:38:20  <sipa> hahaha
547 2017-05-11T19:38:28  <wumpus> interesting proposal
548 2017-05-11T19:38:56  <sipa> so, even though 5us per input/output may not seem much, it's several hours of CPU time for a node syncing from scratch
549 2017-05-11T19:39:04  <BlueMatt> sipa: hmm, i assume you have a pointer to a crypto accumulator somewhere?
550 2017-05-11T19:39:13  <BlueMatt> paper*
551 2017-05-11T19:39:22  <BlueMatt> ehh, I'll just wait for your ml post
552 2017-05-11T19:39:26  *** goksinen has quit IRC
553 2017-05-11T19:39:28  <sipa> BlueMatt: it's a really uninteresting accumulator, as it can't be used to prove anything
554 2017-05-11T19:39:46  <sipa> i'll include some references
555 2017-05-11T19:39:47  *** Dyaheon has joined #bitcoin-core-dev
556 2017-05-11T19:39:58  <gmaxwell> BlueMatt: there have been several papers on related schemes-- however.  Of course, the papers ignore the performance considerations.  And especially in our case we have tradeoffs around block validation latency.
557 2017-05-11T19:40:28  *** dclxvi has quit IRC
558 2017-05-11T19:40:38  <instagibbs> I still want compact proofs, get back to work.
559 2017-05-11T19:40:48  <sipa> also, the DL approach would mean we need an implementation of a fast multiplication mod a (fixed) prime , or a GMP dependency
560 2017-05-11T19:40:48  <instagibbs> (ducks)
561 2017-05-11T19:41:14  <sipa> instagibbs: so one advantage that these things have is that they're not incompatible with other UTXO/TXO commitment approaches
562 2017-05-11T19:41:16  <gmaxwell> in any case, ML post will talk about the tradeoffs and schemes.
563 2017-05-11T19:41:17  <cfields> is ordering relevant? any effects on parallel validation/caching?
564 2017-05-11T19:41:25  <sipa> cfields: it's 100% parallellizable
565 2017-05-11T19:41:30  <gmaxwell> cfields: they're totally independant of ordering.
566 2017-05-11T19:41:32  <wumpus> if at least it can be done in parallel with some of the i/o  (e.g. database lookups) it wouldn't have to add that much to the total validation time
567 2017-05-11T19:41:34  <cfields> whew
568 2017-05-11T19:41:38  <instagibbs> sipa, ack
569 2017-05-11T19:41:54  <gmaxwell> And as sipa is pointing out, unlike other utxo commitments they do not break STXO like schemes where you have nodes that don't store the whole utxo set.
570 2017-05-11T19:41:54  <sipa> ordering is irrelevant... it's effectively a set commitment that is homomorphic wrt to set union and subtraction
571 2017-05-11T19:43:17  <sipa> but if we have this, we could for example log the UTXO commitment hash in the UpdateTip debug.log lines
572 2017-05-11T19:43:17  <BlueMatt> gmaxwell: well the validation latency tradeoffs are mostly removed by commiting to the previous block's utxo commitment, no?
573 2017-05-11T19:43:25  <BlueMatt> is there some reason we should avoid doing so?
574 2017-05-11T19:43:36  *** goksinen has joined #bitcoin-core-dev
575 2017-05-11T19:43:53  <gmaxwell> So the applications I see for this are: an instant gettxouset info,  being able to have updatetip log the UTXO state (making checking nodes much easier), a start on an ability to do an ASSUMEVALID UTXO sync. ('start on' because there is a security/philosophy debate if the value must also be commited to the chain if we're to do an assumevalid like sync)
576 2017-05-11T19:43:55  <sipa> BlueMatt: well we're not even talking about commiting to it in blocks (though that is an interesting possibility later)
577 2017-05-11T19:44:21  <BlueMatt> sipa: great! so lets not do it inline and do it in the background later
578 2017-05-11T19:44:33  <sipa> BlueMatt: and delayed commitments are more complicated if you actually want the latency reduction... you need a backlog and background processing
579 2017-05-11T19:44:33  <BlueMatt> as long as its under 100ms rpc is still instant
580 2017-05-11T19:44:34  <BlueMatt> ish
581 2017-05-11T19:44:46  *** chjj has quit IRC
582 2017-05-11T19:44:54  <gmaxwell> oh well none of this is anywhere near that slow in any case.
583 2017-05-11T19:44:55  <sipa> which would interfere with CPU demand for signature validation
584 2017-05-11T19:45:24  <sipa> gmaxwell: if we need an mod inverse in the RPC, it could be 10ms or so with a naive implementation
585 2017-05-11T19:45:30  <gmaxwell> I think with sutiable caching we're talking about worst case impact, if done inline, on the order of 10ms.
586 2017-05-11T19:45:52  <sipa> anyway, not that much more to say about it
587 2017-05-11T19:45:55  <BlueMatt> i think we can live with 10ms :p
588 2017-05-11T19:46:02  <BlueMatt> anyway, looking forward to the ml post :)
589 2017-05-11T19:46:08  <wumpus> #topic PRs high priority for review
590 2017-05-11T19:46:10  <sipa> i just wanted to give a heads up
591 2017-05-11T19:46:14  <BlueMatt> (in an rpc that would otherwise block cs_main...)
592 2017-05-11T19:46:26  *** joe-fool is now known as jonasschnelli
593 2017-05-11T19:46:41  <sipa> BlueMatt: that 10ms can even run without cs_main
594 2017-05-11T19:46:43  <instagibbs> a less-extreme wallet PR for consideration to 0.15: #10333
595 2017-05-11T19:46:43  <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
596 2017-05-11T19:47:02  <instagibbs> there are still n > 1 reports of extremely high feerates with large num inputs
597 2017-05-11T19:47:02  <BlueMatt> sipa: thats my point :p
598 2017-05-11T19:47:18  <instagibbs> they seem to match up with this case
599 2017-05-11T19:48:16  <wumpus> instagibbs: added 0.15 tag
600 2017-05-11T19:48:26  <instagibbs> thanks
601 2017-05-11T19:48:35  <gmaxwell> Where are we with multiwallet?
602 2017-05-11T19:49:05  <wumpus> there were plenty of review comments on luke-jr's pull, but he hasn't addressed them yet AFAIK
603 2017-05-11T19:49:08  <gmaxwell> I haven't been following it closely because I've been more focused on per-txo/the above commitment stuff/etc.
604 2017-05-11T19:49:17  <gmaxwell> luke-jr: ^ plz.
605 2017-05-11T19:49:19  <jonasschnelli> #8694 needs still rebase
606 2017-05-11T19:49:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
607 2017-05-11T19:49:55  <luke-jr> wumpus: it's pending on jtimon's PR
608 2017-05-11T19:50:05  <wumpus> luke-jr: which one?
609 2017-05-11T19:50:15  <wumpus> I merged a few jtimon PRs this week
610 2017-05-11T19:50:20  <luke-jr> #9494
611 2017-05-11T19:50:22  <gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
612 2017-05-11T19:50:43  <luke-jr> which actually looks mergable?
613 2017-05-11T19:50:49  <wumpus> ok, seems that one is already in high priority for review
614 2017-05-11T19:50:56  <sipa> wumpus: yeah, i marked it so last week
615 2017-05-11T19:51:16  <luke-jr> reason being 8694 touches mapMultiArgs
616 2017-05-11T19:51:25  <wumpus> luke-jr: good to know, will take a look at it soon and merge it
617 2017-05-11T19:51:28  <luke-jr> rather than avoid that, it seems better to just fix the locking for ti
618 2017-05-11T19:51:53  <wumpus> yes
619 2017-05-11T19:52:01  <wumpus> sipa: thanks
620 2017-05-11T19:52:35  *** kexkey has quit IRC
621 2017-05-11T19:52:46  <jonasschnelli> Also, consider reviewing HD-Auto-Restore #10240 (it's currently not in high prio), we should have this in 0.15, otherwise users need to do loop10000(getnewaddress), rescan(genesis) to restore funds.
622 2017-05-11T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
623 2017-05-11T19:53:51  <wumpus> jonasschnelli: added 0.15 milestone
624 2017-05-11T19:53:56  <gmaxwell> jonasschnelli: I'd missed that you got that going. good to hear.
625 2017-05-11T19:54:10  <jonasschnelli> I'll rebase and fix the points soon.
626 2017-05-11T19:54:45  <gmaxwell> I'll take a look at it after I finish my code review on some other PRs that I'm currently working on.
627 2017-05-11T19:55:18  <jonasschnelli> thanks gmaxwell
628 2017-05-11T19:57:05  <instagibbs> 3 minutes
629 2017-05-11T19:57:37  *** chjj has joined #bitcoin-core-dev
630 2017-05-11T19:57:39  <sipa> my #1 is still #10195 :)
631 2017-05-11T19:57:41  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
632 2017-05-11T19:57:42  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
633 2017-05-11T19:57:43  <sipa> eh
634 2017-05-11T19:57:46  <sipa> ah!
635 2017-05-11T19:57:55  <wumpus> yep
636 2017-05-11T19:58:15  <wumpus> #endmeeting
637 2017-05-11T19:58:15  <lightningbot> Meeting ended Thu May 11 19:58:15 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
638 2017-05-11T19:58:15  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.html
639 2017-05-11T19:58:15  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.txt
640 2017-05-11T19:58:15  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-11-19.00.log.html
641 2017-05-11T19:58:23  <jonasschnelli> wumpus: The 3D graphical coin selection was a joke.. though, for educational use, it would be great
642 2017-05-11T19:58:43  <wumpus> jonasschnelli: yes I like the idea, I'd probably use it, I currently always use manual coin selection already
643 2017-05-11T19:58:46  <jonasschnelli> You have a wallet, then you 3d-pick some coins... and you get back a change into your wallet
644 2017-05-11T19:59:02  <jonasschnelli> Yes. I personally always do manual coin selection.
645 2017-05-11T19:59:14  <jonasschnelli> But not sure about the majority of users. :)
646 2017-05-11T19:59:28  <wumpus> jonasschnelli: I think it was in Milan that someone showed some wallet app that had 2d physics effects with coins
647 2017-05-11T19:59:31  <instagibbs> I've never done coin selection personally
648 2017-05-11T19:59:31  <luke-jr> 2D would be enough
649 2017-05-11T19:59:57  <wumpus> don't remember which one, but it looked quite funny
650 2017-05-11T19:59:57  <jonasschnelli> luke-jr: Today everything needs to be 3D,... even 2D. :)
651 2017-05-11T20:00:10  *** waxwing has quit IRC
652 2017-05-11T20:00:15  <gmaxwell> 2d is probably better, 3d illustrations often confuse people about volumes.  But if you show more valuable coins as bigger that will create a false impression that bigger coins cost more to spend, no?
653 2017-05-11T20:00:18  <instagibbs> simply tossing current coin selection and adding random selection would probably be a huge plus sadly.
654 2017-05-11T20:00:21  <luke-jr> jonasschnelli: ☹
655 2017-05-11T20:00:29  <wumpus> I don't think it's *useful* for most people but those things can be fun to play with and people learn how it works
656 2017-05-11T20:00:47  <jonasschnelli> 3D would be in a form you woudnl't recognize. The depth and shadows only slighly change when you drag the coins.
657 2017-05-11T20:01:06  <wumpus> jonasschnelli: oh, so no tetris blocks? :-)
658 2017-05-11T20:01:18  <jonasschnelli> heh
659 2017-05-11T20:02:11  <jonasschnelli> Someone I feel if – from the beginning – coin selection would have been a "manual process", people would understand Bitcoin transactions better.
660 2017-05-11T20:02:18  <wumpus> plane tiling puzzle but with the goal to get as close as possible to the spend value :p
661 2017-05-11T20:02:25  <jonasschnelli> Also the "feerate" problem.. that it's not absolute.
662 2017-05-11T20:02:28  *** Firescar96 has quit IRC
663 2017-05-11T20:02:36  <wumpus> jonasschnelli: I tend to agree
664 2017-05-11T20:03:10  <gmaxwell> A better visualization might be be the coins being sized based on how much weight they add to the txn, and different metals based on value. :P
665 2017-05-11T20:03:16  <jonasschnelli> Automatic coin selection may be something large wallets / exchanges are using.
666 2017-05-11T20:03:31  <jonasschnelli> gmaxwell: Oh. Different metals... I like this.
667 2017-05-11T20:03:59  <instagibbs> "Silver, since when did I have Litecoin?"
668 2017-05-11T20:04:11  <jonasschnelli> With a SW badge? :-)
669 2017-05-11T20:04:41  <luke-jr> gmaxwell: yeah, I was thinking numbers rather than colours
670 2017-05-11T20:04:44  <luke-jr> maybe both?
671 2017-05-11T20:05:08  *** SopaXorzTaker has quit IRC
672 2017-05-11T20:05:27  <wumpus> niec idea
673 2017-05-11T20:05:31  <gmaxwell> luke-jr: well yea, both of course.
674 2017-05-11T20:05:38  *** Guest50211 has quit IRC
675 2017-05-11T20:06:01  <luke-jr> gold for > 1 ᵐTBC, silver for > ᵗTBC, bronze for > 1 TBC, and "plastic" for smaller
676 2017-05-11T20:06:15  * luke-jr hides
677 2017-05-11T20:06:17  <gmaxwell> hah
678 2017-05-11T20:10:38  *** jcliff42 has joined #bitcoin-core-dev
679 2017-05-11T20:12:58  *** waxwing has joined #bitcoin-core-dev
680 2017-05-11T20:16:38  *** jcliff42 has joined #bitcoin-core-dev
681 2017-05-11T20:17:02  *** jcliff42 has joined #bitcoin-core-dev
682 2017-05-11T20:19:50  *** jcliff42 has quit IRC
683 2017-05-11T20:26:49  *** cbits has quit IRC
684 2017-05-11T20:28:16  *** goksinen has quit IRC
685 2017-05-11T20:36:30  *** rgod has joined #bitcoin-core-dev
686 2017-05-11T20:37:40  *** d_t has joined #bitcoin-core-dev
687 2017-05-11T20:38:53  <instagibbs> my p2p-fullblocks test is timing out on a couple of my machines... is this known issue
688 2017-05-11T20:39:34  *** goksinen has joined #bitcoin-core-dev
689 2017-05-11T20:40:17  *** moli_ has joined #bitcoin-core-dev
690 2017-05-11T20:41:17  <instagibbs> oh scratch that, this seems to be an assertion error
691 2017-05-11T20:42:08  *** d_t has quit IRC
692 2017-05-11T20:42:58  *** mol has quit IRC
693 2017-05-11T20:45:29  *** cbits has joined #bitcoin-core-dev
694 2017-05-11T20:49:29  *** Guyver2 has quit IRC
695 2017-05-11T20:53:36  *** Sprh has joined #bitcoin-core-dev
696 2017-05-11T21:04:02  *** gm2052 has joined #bitcoin-core-dev
697 2017-05-11T21:06:16  *** gm2051 has quit IRC
698 2017-05-11T21:13:42  *** Firescar96 has joined #bitcoin-core-dev
699 2017-05-11T21:18:25  *** JackH has quit IRC
700 2017-05-11T21:23:40  *** [Author] has quit IRC
701 2017-05-11T21:27:58  *** BashCo has joined #bitcoin-core-dev
702 2017-05-11T21:28:16  *** gm2053 has joined #bitcoin-core-dev
703 2017-05-11T21:28:47  *** [Author] has joined #bitcoin-core-dev
704 2017-05-11T21:31:55  *** gm2052 has quit IRC
705 2017-05-11T21:33:02  *** cbits has quit IRC
706 2017-05-11T21:34:21  *** talmai has quit IRC
707 2017-05-11T21:35:01  *** gm2052 has joined #bitcoin-core-dev
708 2017-05-11T21:38:14  *** gm2053 has quit IRC
709 2017-05-11T21:39:10  *** shesek has quit IRC
710 2017-05-11T21:44:32  *** kadoban has quit IRC
711 2017-05-11T21:50:11  *** kadoban has joined #bitcoin-core-dev
712 2017-05-11T21:58:40  *** Sprh has quit IRC
713 2017-05-11T22:00:36  <gmaxwell> jonasschnelli: sipa: petertodd: luke-jr:   Bitcoin-dev is as useful as we make it.  There are certian reliable parties that will crap-post reply to every useful idea posted to the list.  When we respond directly point by point arguing their foolish positions, the list becomes useless for technical discussions.
714 2017-05-11T22:00:46  *** protomar has quit IRC
715 2017-05-11T22:01:26  <gmaxwell> I would strongly recommend that whenever you get a message from someone who has reliably made useless progress blocking responses that you do not respond to them point by point, but instead make sure their concerns are addressed in a message responding to a productive point raised by someone else.
716 2017-05-11T22:02:22  <gmaxwell> Otherwise, the thread just becomes an endless argument over stupidity and people who are likely to make reasonable responses will ignore the thread.
717 2017-05-11T22:04:32  *** kadoban_ has joined #bitcoin-core-dev
718 2017-05-11T22:04:51  *** kadoban has quit IRC
719 2017-05-11T22:07:12  *** rgod has quit IRC
720 2017-05-11T22:22:10  *** mol has joined #bitcoin-core-dev
721 2017-05-11T22:24:57  *** moli_ has quit IRC
722 2017-05-11T22:26:35  *** Firescar96 has quit IRC
723 2017-05-11T22:26:57  *** mol has quit IRC
724 2017-05-11T22:29:14  <sipa> frequency of depths of blocks downloaded from my node over the past 3 months: http://bitcoin.sipa.be/depths.png
725 2017-05-11T22:30:29  *** moli_ has joined #bitcoin-core-dev
726 2017-05-11T22:30:51  *** moli_ has quit IRC
727 2017-05-11T22:31:20  *** moli_ has joined #bitcoin-core-dev
728 2017-05-11T22:35:25  *** gm2053 has joined #bitcoin-core-dev
729 2017-05-11T22:38:20  *** d_t has joined #bitcoin-core-dev
730 2017-05-11T22:39:41  *** gm2052 has quit IRC
731 2017-05-11T22:42:30  *** gm2052 has joined #bitcoin-core-dev
732 2017-05-11T22:42:36  *** d_t has quit IRC
733 2017-05-11T22:43:27  *** goksinen has quit IRC
734 2017-05-11T22:44:40  *** gm2051 has joined #bitcoin-core-dev
735 2017-05-11T22:45:36  *** gm2053 has quit IRC
736 2017-05-11T22:47:32  *** gm2052 has quit IRC
737 2017-05-11T22:53:05  *** NewLiberty has quit IRC
738 2017-05-11T23:05:16  *** Dyaheon has quit IRC
739 2017-05-11T23:06:27  *** Dyaheon has joined #bitcoin-core-dev
740 2017-05-11T23:14:48  *** gm2052 has joined #bitcoin-core-dev
741 2017-05-11T23:18:39  *** gm2051 has quit IRC
742 2017-05-11T23:20:04  *** gm2053 has joined #bitcoin-core-dev
743 2017-05-11T23:23:56  *** gm2052 has quit IRC
744 2017-05-11T23:30:58  *** NewLiberty has joined #bitcoin-core-dev
745 2017-05-11T23:34:55  *** gm2052 has joined #bitcoin-core-dev
746 2017-05-11T23:38:52  *** gm2053 has quit IRC
747 2017-05-11T23:39:57  *** jannes has quit IRC
748 2017-05-11T23:45:17  *** chatter29 has joined #bitcoin-core-dev
749 2017-05-11T23:45:24  <chatter29> hey guys
750 2017-05-11T23:45:34  <chatter29> allah is doing
751 2017-05-11T23:45:40  <chatter29> sun is not doing allah is doing
752 2017-05-11T23:45:41  <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
753 2017-05-11T23:45:59  <chatter29> As-salāmu ʿalaykum (Arabic: السَّلَامُ عَلَيْكُمْ‎‎ [asːaˈlaːmu ʕaˈlaikum]) is a greeting in Arabic that means "peace be upon you". The greeting is a standard salutation among Muslims and is routinely used whenever and wherever Muslims gather and interact, whether socially or within worship and other contexts. [1] The typical response to the greeti
754 2017-05-11T23:45:59  <chatter29> ng is waʿalaykumu s-salām (وَعَلَيْكُم السَّلَام [waʕaˈlaikumu sːaˈlaːm]; "and upon you, peace").
755 2017-05-11T23:46:03  *** ChanServ sets mode: +o luke-jr
756 2017-05-11T23:46:06  *** chatter29 was kicked by luke-jr (spam)
757 2017-05-11T23:46:09  *** luke-jr sets mode: -o luke-jr
758 2017-05-11T23:46:29  *** gm2053 has joined #bitcoin-core-dev
759 2017-05-11T23:50:11  *** chatter29 has joined #bitcoin-core-dev
760 2017-05-11T23:50:37  *** gm2052 has quit IRC
761 2017-05-11T23:50:59  *** kline has joined #bitcoin-core-dev
762 2017-05-11T23:51:42  *** chatter29 has quit IRC
763 2017-05-11T23:52:22  *** kline has left #bitcoin-core-dev
764 2017-05-11T23:54:10  *** Giszmo has quit IRC
765 2017-05-11T23:57:27  *** NewLiberty has quit IRC
766 2017-05-11T23:57:58  *** waxwing__ has joined #bitcoin-core-dev
767 2017-05-11T23:59:10  *** mol has joined #bitcoin-core-dev