1 2016-09-21T00:33:16  *** Chris_Stewart_5 has quit IRC
  2 2016-09-21T00:35:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  3 2016-09-21T00:43:52  *** moli has joined #bitcoin-core-dev
  4 2016-09-21T00:46:03  *** mol has quit IRC
  5 2016-09-21T00:46:27  *** brg444 has joined #bitcoin-core-dev
  6 2016-09-21T00:46:55  *** Ylbam has quit IRC
  7 2016-09-21T01:04:15  *** analpaper has joined #bitcoin-core-dev
  8 2016-09-21T01:22:17  *** Chris_Stewart_5 has quit IRC
  9 2016-09-21T01:39:59  *** PaulCapestany has joined #bitcoin-core-dev
 10 2016-09-21T01:40:26  *** dcousens has joined #bitcoin-core-dev
 11 2016-09-21T01:57:26  *** btcdrak has quit IRC
 12 2016-09-21T01:59:36  <phantomcircuit> is there some reason im not aware of that the wallet functions aren't acquiring the lock themselves?
 13 2016-09-21T01:59:46  <phantomcircuit> instead of relying on the caller to have acquired the lock?
 14 2016-09-21T02:11:36  *** brg444 has quit IRC
 15 2016-09-21T02:13:31  *** jchrome has joined #bitcoin-core-dev
 16 2016-09-21T02:29:08  *** jchrome has quit IRC
 17 2016-09-21T02:30:14  *** jchrome has joined #bitcoin-core-dev
 18 2016-09-21T02:39:23  <phantomcircuit> luke-jr: ^
 19 2016-09-21T02:40:00  <phantomcircuit> it *should* be safe for me to simpyl add LOCK(cs_wallet); calls to all methods which assume a lock? (which is basically all of them)
 20 2016-09-21T02:41:35  <luke-jr> phantomcircuit: my guess would be so they could be used recursively
 21 2016-09-21T02:53:24  *** go1111111 has quit IRC
 22 2016-09-21T02:56:07  *** Alopex has quit IRC
 23 2016-09-21T02:57:12  *** Alopex has joined #bitcoin-core-dev
 24 2016-09-21T03:01:35  *** Atomic_zEU0b has joined #bitcoin-core-dev
 25 2016-09-21T03:02:04  *** Atomic_zEU0b has left #bitcoin-core-dev
 26 2016-09-21T03:02:35  <Atomic_zEU0b> hey
 27 2016-09-21T03:08:53  *** jchrome has left #bitcoin-core-dev
 28 2016-09-21T03:15:31  *** dcousens has quit IRC
 29 2016-09-21T03:18:22  *** Alopex has quit IRC
 30 2016-09-21T03:19:27  *** Alopex has joined #bitcoin-core-dev
 31 2016-09-21T03:19:38  <phantomcircuit> gmaxwell: the LOCK construct is recursive right?
 32 2016-09-21T03:33:06  <luke-jr> pretty sure it isn't. or at least can't be relied on to be.
 33 2016-09-21T03:42:09  *** dcousens has joined #bitcoin-core-dev
 34 2016-09-21T03:53:21  *** jchrome has joined #bitcoin-core-dev
 35 2016-09-21T04:00:03  *** dermoth has quit IRC
 36 2016-09-21T04:00:37  *** dermoth has joined #bitcoin-core-dev
 37 2016-09-21T04:08:02  *** sdaftuar has quit IRC
 38 2016-09-21T04:18:15  *** sdaftuar has joined #bitcoin-core-dev
 39 2016-09-21T04:58:01  *** Alopex has quit IRC
 40 2016-09-21T04:58:01  *** davec has quit IRC
 41 2016-09-21T04:58:20  *** davec has joined #bitcoin-core-dev
 42 2016-09-21T04:59:06  *** Alopex has joined #bitcoin-core-dev
 43 2016-09-21T05:06:14  *** justan0theruser has joined #bitcoin-core-dev
 44 2016-09-21T05:06:23  *** justanotheruser has quit IRC
 45 2016-09-21T05:11:21  *** kyletorpey has quit IRC
 46 2016-09-21T05:12:32  *** kyletorpey has joined #bitcoin-core-dev
 47 2016-09-21T05:20:44  *** analpaper has quit IRC
 48 2016-09-21T05:27:46  *** kadoban has quit IRC
 49 2016-09-21T05:38:20  <wumpus> phantomcircuit: yes, the default mutex used in bitcoin core is a recursive one
 50 2016-09-21T05:39:05  <wumpus> we'd rather have it otherwise, there are a few solid software engineering reasons to avoid recursive mutexes, but that's part of our inheritance and it's terribly difficult to change (and be sure of the result)
 51 2016-09-21T05:39:36  <wumpus> note that new code in general tries to use normal, single-use mutexes
 52 2016-09-21T05:40:57  *** mn3monic has joined #bitcoin-core-dev
 53 2016-09-21T05:56:10  *** paveljanik has joined #bitcoin-core-dev
 54 2016-09-21T05:56:10  *** paveljanik has joined #bitcoin-core-dev
 55 2016-09-21T06:08:48  <luke-jr> wumpus: pretty sure I hit a deadlock from locking the same mutex twice in a thread, fwiw
 56 2016-09-21T06:09:25  <wumpus> that is very possible, but not with the main, wallet locks and such as they are recursive mutexes
 57 2016-09-21T06:09:31  *** Ylbam has joined #bitcoin-core-dev
 58 2016-09-21T06:10:18  <wumpus> you can try locking them 100 times in a loop in the same thread, they just keep track of a counter, so as long as you unlock the same number of times you will be fine
 59 2016-09-21T06:11:25  <luke-jr> wumpus: I guess I should just close https://github.com/bitcoin/bitcoin/pull/8687 and simply remove the call in a new PR?
 60 2016-09-21T06:11:56  <wumpus> let's close it in favor of #8765
 61 2016-09-21T06:12:28  <luke-jr> oh, missed that
 62 2016-09-21T06:12:37  <wumpus> he had missed your pull too
 63 2016-09-21T06:12:45  <GitHub113> [bitcoin] laanwj closed pull request #8687: Bugfix: RPC/Wallet: removeprunedfunds should flush the wallet db (master...bugfix_removeprunedfunds) https://github.com/bitcoin/bitcoin/pull/8687
 64 2016-09-21T06:15:13  *** btcdrak has joined #bitcoin-core-dev
 65 2016-09-21T06:16:02  <GitHub23> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1c24d5f63720...b4f53641a95d
 66 2016-09-21T06:16:02  <GitHub23> bitcoin/master c6f5ca8 Jonas Schnelli: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds
 67 2016-09-21T06:16:03  <GitHub23> bitcoin/master b4f5364 Wladimir J. van der Laan: Merge #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds...
 68 2016-09-21T06:16:12  <GitHub106> [bitcoin] laanwj closed pull request #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds (master...2016/09/flush_wallet_dump) https://github.com/bitcoin/bitcoin/pull/8765
 69 2016-09-21T06:16:15  *** dcousens has quit IRC
 70 2016-09-21T06:27:16  *** MarcoFalke has joined #bitcoin-core-dev
 71 2016-09-21T06:38:01  *** Alopex has quit IRC
 72 2016-09-21T06:39:07  *** Alopex has joined #bitcoin-core-dev
 73 2016-09-21T06:55:35  *** rubensayshi has joined #bitcoin-core-dev
 74 2016-09-21T07:15:15  *** paveljanik has quit IRC
 75 2016-09-21T07:49:25  *** tucenaber has quit IRC
 76 2016-09-21T07:50:28  *** ___tau___ has quit IRC
 77 2016-09-21T08:04:50  *** molz has joined #bitcoin-core-dev
 78 2016-09-21T08:07:36  *** moli has quit IRC
 79 2016-09-21T08:31:42  *** ill has quit IRC
 80 2016-09-21T08:38:13  *** mrkent has quit IRC
 81 2016-09-21T08:39:33  <MarcoFalke> jonasschnelli: Would it be hard to use the theme for the text+background as luke-jr suggests?
 82 2016-09-21T08:39:43  <MarcoFalke> Anyway style nits can be fixed later, 8371 looks good now
 83 2016-09-21T08:40:27  <MarcoFalke> This is the most important gui change for 0.14. Better get it in sooner than later
 84 2016-09-21T08:40:32  <jonasschnelli> MarcoFalke: Yes. This could be done later...
 85 2016-09-21T08:40:45  <luke-jr> indeed
 86 2016-09-21T08:40:58  <jonasschnelli> Also. I'm not sure if theme based colors together with the icon and the progress bar will look nice
 87 2016-09-21T08:41:12  <jonasschnelli> I guess we also would need to ensure the singlecoloricon fits the theme...
 88 2016-09-21T08:41:22  <jonasschnelli> also the blackish overlay is something that looks good IMO
 89 2016-09-21T08:41:39  <jonasschnelli> gives a look that its something "important" to read..
 90 2016-09-21T08:41:56  <luke-jr> singlecoloricon is designed specifically to fit the theme :p
 91 2016-09-21T08:42:11  <jonasschnelli> if we just use the theme colors, it might be white with black text and not really distinctable between the rest of the UI elements
 92 2016-09-21T08:42:24  *** DigiByteDev has joined #bitcoin-core-dev
 93 2016-09-21T08:42:38  <jonasschnelli> the inverted colors as an overlay make sense from an UX perspetive IMO.
 94 2016-09-21T08:43:40  <luke-jr> I'm not aware of a single app that inverts colours for modal dialogs.
 95 2016-09-21T08:48:16  <jonasschnelli> Luke-Jr: how should it look then?
 96 2016-09-21T08:50:38  <luke-jr> however modal dialogs normally look for the particular user's style
 97 2016-09-21T08:51:56  <jonasschnelli> But it's not a modal dialog... it's an overlay.
 98 2016-09-21T08:52:10  <luke-jr> good UX lies in behaving and looking as the user expects IMO
 99 2016-09-21T08:52:17  <luke-jr> jonasschnelli: what's the difference?
100 2016-09-21T08:52:33  <jonasschnelli> Its in the same window
101 2016-09-21T08:52:52  <jonasschnelli> It overlays the controls.
102 2016-09-21T08:53:12  <jonasschnelli> Using a QDialog with modal flag would be wrong IMO
103 2016-09-21T08:53:50  <luke-jr> preventing interaction with the controls is precisely what model dialogs are meant to be used for.
104 2016-09-21T08:53:54  <jonasschnelli> We could try to use the theme color for the black, hiding-part and a theme color for the overlay-info-layer and the text
105 2016-09-21T08:54:13  <jonasschnelli> Yes. But do you think a QDialog with modal flag would look appropriate?
106 2016-09-21T08:54:14  <luke-jr> the key distinction I see in this case, is that the dialog needs to go away on its own when the process completes
107 2016-09-21T08:54:39  * luke-jr ponders what similar things exist
108 2016-09-21T08:54:52  <sipa> it also doesn't need preventing interaction with the entire application
109 2016-09-21T08:55:03  <sipa> opening the debug window presumably should work fine
110 2016-09-21T08:55:05  <luke-jr> sipa: good point
111 2016-09-21T08:55:58  <jonasschnelli> Yes. It a partial-modal overlay. :)
112 2016-09-21T08:56:05  <luke-jr> KMail shows an overlay while it loads a folder
113 2016-09-21T08:56:13  <luke-jr> so it seems the overlay stuff is standard
114 2016-09-21T08:56:18  <luke-jr> at least to some degree
115 2016-09-21T08:56:38  <jonasschnelli> I think we could try to attach it more to the theme colors once its merged
116 2016-09-21T08:56:58  <jonasschnelli> before we do cosmetic changes, we should address the problem that people download Core and start receiving funds that are then stuck.
117 2016-09-21T08:57:01  <luke-jr> yes, I agree, this doesn't need to hold back merging
118 2016-09-21T08:57:04  <sipa> use the text color as background and background color as text? :)
119 2016-09-21T08:57:11  <sipa> yes agree, not a blocker
120 2016-09-21T08:57:13  <jonasschnelli> Yes. Something like that
121 2016-09-21T08:57:14  <wumpus> +1 on getting it merged
122 2016-09-21T08:57:24  <sipa> ha, blocker... for a modal overlay
123 2016-09-21T08:57:31  <jonasschnelli> heh!
124 2016-09-21T08:57:39  <wumpus> this is here to solve a serious problem that ends up with a lot of sob stories in my mail, not just to look pretty
125 2016-09-21T08:57:41  <wumpus> hah
126 2016-09-21T08:58:12  <wumpus> even an ugly black 'censored' box would be better than what there is now :p
127 2016-09-21T08:58:21  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8371 needs another ACK (or a re-ack from MarcoFalke) before I merge it.
128 2016-09-21T08:58:21  <luke-jr> lol
129 2016-09-21T08:58:29  <MarcoFalke> ACK
130 2016-09-21T08:58:38  <sipa> jonasschnelli: is the header count still wrong due to that signal reporting the best candidate rather than the best header?
131 2016-09-21T08:58:43  <MarcoFalke> The github review sucks
132 2016-09-21T08:58:53  <jonasschnelli> sipa: Should be right now... because...
133 2016-09-21T08:59:12  * jonasschnelli is checking the code...
134 2016-09-21T08:59:17  <sipa> we should discuss how to integrate the ack/nack/... things with github review
135 2016-09-21T08:59:29  <sipa> what if you approve with a nack? :)
136 2016-09-21T08:59:33  <MarcoFalke> Don't use github review
137 2016-09-21T08:59:33  <jonasschnelli> clientModel->getHeaderTipTime()
138 2016-09-21T08:59:38  <luke-jr> is BlueMatt annoyed at it still? :P
139 2016-09-21T09:00:01  <jonasschnelli> sipa: https://github.com/bitcoin/bitcoin/pull/8371/files#diff-0db7dd184df07a48c307ccc182021a68R722
140 2016-09-21T09:00:20  <sipa> MarcoFalke: why not?
141 2016-09-21T09:00:25  <jonasschnelli> I take the time and height directly from pindexBestHeader
142 2016-09-21T09:00:34  <wumpus> why does github review suck? Ithink combining multple comments into one review is pretty useful
143 2016-09-21T09:00:36  <jonasschnelli> (each time the singal fires)
144 2016-09-21T09:00:39  <MarcoFalke> It shows the changes as approved by me, even though new commits were pushed
145 2016-09-21T09:00:44  <sipa> wumpus: agree
146 2016-09-21T09:00:44  *** AaronvanW has quit IRC
147 2016-09-21T09:01:01  <sipa> MarcoFalke: it does tell you what changes the review was for, no?
148 2016-09-21T09:01:07  <MarcoFalke> wumpus: But it does not hide the comments when they are solved
149 2016-09-21T09:01:12  <jonasschnelli> MarcoFalke: but the "timeline" implies that you have reviewd on older state?
150 2016-09-21T09:01:15  <jonasschnelli> thats indeed bad
151 2016-09-21T09:01:24  <jonasschnelli> Do they go away if a commit gets added?
152 2016-09-21T09:01:48  <MarcoFalke> Yes "timeline". But it is possible to push commits such that they appear in the past
153 2016-09-21T09:01:50  <jonasschnelli> I really dislike the non-removing comments on the source-code...
154 2016-09-21T09:01:55  <wumpus> MarcoFalke: that's the same with an ACK, really, the reason for speicfying the commit it was against is to be able to check what exactly you reviewed later, not to de-approve on changes
155 2016-09-21T09:02:06  <jonasschnelli> They stay also after a force push or commit that removes that code part
156 2016-09-21T09:02:12  <wumpus> and you can still mention the commit in review comments if you want
157 2016-09-21T09:02:47  <wumpus> jonasschnelli: that's slightly annoying, yes, otoh it makes the review history clearer
158 2016-09-21T09:03:03  <wumpus> so people don't, say, suggest the opposite thing when something has been discussed already
159 2016-09-21T09:03:09  <wumpus> hiding can be pretty annoying in that regard
160 2016-09-21T09:03:17  <jonasschnelli> Yes. That indeed true..
161 2016-09-21T09:03:17  <sipa> i hate it when review commemts automatically disappear
162 2016-09-21T09:03:32  <sipa> i want to judge whether a comment still applies
163 2016-09-21T09:03:37  <wumpus> yes
164 2016-09-21T09:03:42  <jonasschnelli> I just fear very large pages with endless amount of comments/reviews
165 2016-09-21T09:03:51  <wumpus> indeed, github's judgement is not very good there
166 2016-09-21T09:03:55  <sipa> you can explicitly mark as resolved, no?
167 2016-09-21T09:03:56  <jonasschnelli> But right... it makes stuff more obvious for new reviewers
168 2016-09-21T09:04:02  <jonasschnelli> I guess no
169 2016-09-21T09:04:07  <luke-jr> sipa: that'd be nice, but I've never seen it
170 2016-09-21T09:04:11  <wumpus> it just looks if the line changes and then considered the comment invalid
171 2016-09-21T09:04:35  <jonasschnelli> wumpus: I think for review-comments, they stay even if the lines gets removed afterwards
172 2016-09-21T09:04:41  <sipa> and it used to differ based on whether it was a commit comment or pr comment
173 2016-09-21T09:04:55  <MarcoFalke> So use the review thing when you want the comments to stay. And use the old comment thing when the feedback should vanish after being addressed.
174 2016-09-21T09:05:12  <luke-jr> MarcoFalke: and then GitHub will change the behaviour under you :P
175 2016-09-21T09:05:19  <sipa> MarcoFalke: just a rebase can make comments disappear
176 2016-09-21T09:06:14  <MarcoFalke> Well, I use comments to indicate merge conflicts sometimes. I expect them to disappear after
177 2016-09-21T09:06:48  *** AaronvanW has joined #bitcoin-core-dev
178 2016-09-21T09:07:44  <wumpus> MarcoFalke: you can still add 'single comments'
179 2016-09-21T09:08:10  <wumpus> I'd expect them to still be treated the same as before on changes, unsure though
180 2016-09-21T09:09:55  <wumpus> 'disappear' is not the right word, I think they never fully disappear, just get collapsed?
181 2016-09-21T09:10:21  <wumpus> 'this comment is on a previous version of ...'
182 2016-09-21T09:10:34  *** justan0theruser has quit IRC
183 2016-09-21T09:11:24  <MarcoFalke> Jup, single comments are the old fashioned comments
184 2016-09-21T09:11:43  <MarcoFalke> wumpus: Should I add the DEFAULT_DISABLEWALLET=false in this pull?
185 2016-09-21T09:12:07  <wumpus> MarcoFalke: would be nice to do that in one go, yes
186 2016-09-21T09:12:27  <jonasschnelli> Luke-Jr: I agree that it would be better to first merge https://github.com/bitcoin/bitcoin/pull/8694 and then improving multiwallet stuff.
187 2016-09-21T09:12:53  <jonasschnelli> not sure how easy it is to get this merged in a whole
188 2016-09-21T09:13:13  <luke-jr> perhaps I should split the refactors from multiwallet?
189 2016-09-21T09:13:14  <jonasschnelli> Luke-Jr: The Qt wallet switch dropdown is also present when you only have a single wallet, right?
190 2016-09-21T09:13:15  <wumpus> pretty difficult, better to do the refactoring needed step by step
191 2016-09-21T09:13:26  <MarcoFalke> Agree
192 2016-09-21T09:13:27  <jonasschnelli> wumpus: Yes. I though so...
193 2016-09-21T09:13:28  <luke-jr> jonasschnelli: no, it's hidden with a single wallet
194 2016-09-21T09:13:42  <luke-jr> wumpus: it is step by step, in commits :p
195 2016-09-21T09:13:52  <MarcoFalke> jonasschnelli's pr is already "minimal". Though several hundred lines
196 2016-09-21T09:14:03  <wumpus> if you want to know why, look what killed the first multi-wallet pull years ago, too much changed at once
197 2016-09-21T09:14:05  <jonasschnelli> Mostly search and replace thought: https://github.com/bitcoin/bitcoin/pull/8764
198 2016-09-21T09:14:07  <wumpus> yes jonasschnelli's PR is minimal
199 2016-09-21T09:14:13  <wumpus> luke-jr's not so much
200 2016-09-21T09:14:17  <jonasschnelli> I think we need to go in small step PRs
201 2016-09-21T09:14:38  <luke-jr> ok, I'll open a new PR with just some refactoring
202 2016-09-21T09:14:51  <MarcoFalke> Also, I like the approach of defaultWallet()
203 2016-09-21T09:14:51  <luke-jr> unless you think I should do each refactor separately.. ._.
204 2016-09-21T09:14:53  <wumpus> I mean there's obviously a compromise here, try to change the world in one PR and no one has the energy to review it, change too little and it's death by a thousand cuts as people don't see the story anymore
205 2016-09-21T09:15:16  <jonasschnelli> Luke-Jr: Yes. And sorry for "shooting" in the same direction with https://github.com/bitcoin/bitcoin/pull/8764 I like your mutliwallet PR and really like to boost getting this in
206 2016-09-21T09:16:05  <wumpus> lol I had an adverse reaction on seeing the word 'boost' even though it's used in a completely different context
207 2016-09-21T09:16:11  <luke-jr> XD
208 2016-09-21T09:16:13  <jonasschnelli> hehe
209 2016-09-21T09:16:18  * wumpus reads too much code
210 2016-09-21T09:17:12  <jonasschnelli> Luke-Jr: What do you think about exposing the addWallet stuff to RPC?
211 2016-09-21T09:17:24  <jonasschnelli> the -wallet= approach of adding wallets is kinda limited on runtime
212 2016-09-21T09:17:32  <luke-jr> jonasschnelli: intentionally so
213 2016-09-21T09:17:38  <wumpus> jonasschnelli: can be sone later
214 2016-09-21T09:17:43  <luke-jr> for the "too much in one PR" reason
215 2016-09-21T09:17:49  <jonasschnelli> Yes. Thats true
216 2016-09-21T09:17:57  <wumpus> runtime wallet loading and unloading is super-spiffy,but harder to get right
217 2016-09-21T09:17:59  <luke-jr> changing wallets at runtime makes this a lot more complex
218 2016-09-21T09:18:04  <wumpus> yes,that
219 2016-09-21T09:18:13  <jonasschnelli> Okay. I see. Agree on that.
220 2016-09-21T09:18:46  <luke-jr> (especially closing)
221 2016-09-21T09:18:48  <wumpus> same as with the wallet HD support, it's better to do small (but significant) steps at a time
222 2016-09-21T09:18:54  <jonasschnelli> Luke-Jr: In my tests, the Qt drop-down stays there even with a single wallet
223 2016-09-21T09:19:46  <luke-jr> jonasschnelli: hmm, that's a bug then
224 2016-09-21T09:19:56  <luke-jr> IMO
225 2016-09-21T09:20:15  <luke-jr> (at least in the current stage, I don't think normal users should be exposed to the feature)
226 2016-09-21T09:20:39  <luke-jr> oh, the *debug* dropdown should stay with only one wallet though
227 2016-09-21T09:20:43  <luke-jr> because it has a (none) option
228 2016-09-21T09:21:27  <jonasschnelli> Okay. I'll test some more...
229 2016-09-21T09:21:34  <luke-jr> actually tempting to make that the default, so users have yet one more step to compromise their wallet..
230 2016-09-21T09:22:13  <wumpus> how does this pushing-to-others-branches work? say I want to remove the double space in #8769 without that user openeing yet anouther pull request because he can't squash
231 2016-09-21T09:22:38  <MarcoFalke> jup
232 2016-09-21T09:22:40  <luke-jr> wumpus: never tried, but I speculate you'd do something like the origin-pull remote trick
233 2016-09-21T09:22:40  <MarcoFalke> I tried it
234 2016-09-21T09:22:44  <wumpus> "Add more commits by pushing to the patch-4 branch on unsystemizer/bitcoin." ah
235 2016-09-21T09:22:48  <wumpus> let's just try that
236 2016-09-21T09:22:56  <MarcoFalke> git add remote unsys ...
237 2016-09-21T09:23:03  <luke-jr> oh, it actually gives you access to his personal repo? :o
238 2016-09-21T09:23:03  <MarcoFalke> git push unsys patch-4 -f
239 2016-09-21T09:23:13  <MarcoFalke> luke-jr: Only this branch, IIRC
240 2016-09-21T09:23:29  <wumpus> MarcoFalke: yes I was thining to difficult, I thought I had to push to some special pulls branch on bitcoin/bitcoin
241 2016-09-21T09:23:31  <luke-jr> what happens if I open a PR for one of MarcoFalke's branches? <.<
242 2016-09-21T09:24:01  <MarcoFalke> Hmm, good question
243 2016-09-21T09:24:17  <luke-jr> MarcoFalke: got something to PR I can try it with?  :D
244 2016-09-21T09:24:32  <MarcoFalke> One sec
245 2016-09-21T09:25:03  <luke-jr> dad932c needs to be fixed, if you want something trivial
246 2016-09-21T09:26:52  <wumpus> "git push -f git@github.com:unsystemizer/bitcoin.git HEAD:patch-4" seems to have worked
247 2016-09-21T09:30:47  <wumpus> feels a bit like intruding to push to someone elses repository, but okay, it's very practical in this case
248 2016-09-21T09:31:01  <MarcoFalke> luke-jr: https://github.com/bitcoin/bitcoin/compare/master...MarcoFalke:Mf1609-ContributeDoc?expand=1
249 2016-09-21T09:31:58  <GitHub92> [bitcoin] luke-jr opened pull request #8771: CONTRIBUTING: Mention not to open several pulls (master...Mf1609-ContributeDoc) https://github.com/bitcoin/bitcoin/pull/8771
250 2016-09-21T09:32:06  <luke-jr> no checkbox in this case
251 2016-09-21T09:32:49  <GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b4f53641a95d...84c9a048559d
252 2016-09-21T09:32:50  <GitHub93> bitcoin/master 04d91f4 unsystemizer: Trivial: Fix ISO URL, capitalization...
253 2016-09-21T09:32:50  <GitHub93> bitcoin/master 84c9a04 Wladimir J. van der Laan: Merge #8769: Trivial: Fix ISO URL, capitalization...
254 2016-09-21T09:32:51  <luke-jr> hm, review won't let me set a review-type for the PR either. :P
255 2016-09-21T09:32:59  <GitHub138> [bitcoin] laanwj closed pull request #8769: Trivial: Fix ISO URL, capitalization (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8769
256 2016-09-21T09:34:03  *** jchrome has quit IRC
257 2016-09-21T09:36:33  <MarcoFalke> wumpus, can you do "git push -f git@github.com:MarcoFalke/bitcoin.git HEAD:Mf1609-ContributeDoc"?
258 2016-09-21T09:36:58  <wumpus> sure, does it matter what I overwrite it with?
259 2016-09-21T09:37:06  <luke-jr> it should fail anyway
260 2016-09-21T09:37:07  <MarcoFalke> no
261 2016-09-21T09:37:18  <MarcoFalke> does not matter
262 2016-09-21T09:37:19  <wumpus>  ! [remote rejected] HEAD -> Mf1609-ContributeDoc (permission denied)
263 2016-09-21T09:37:52  <luke-jr> good, GitHub isn't totally incompetent. ☺
264 2016-09-21T09:38:43  <wumpus> the access control code just became extremely complex though, wouldn't be surprised if someone still discovered a loophole
265 2016-09-21T09:39:41  <wumpus> on some level this feature creeps me out
266 2016-09-21T09:39:49  <MarcoFalke> Open a pull request to bitcoin:master in some other repo. Force push to bitcoin:master...
267 2016-09-21T09:39:52  <sipa> likewise
268 2016-09-21T09:39:59  <wumpus> git is meant to be authority-less
269 2016-09-21T09:40:06  <luke-jr> it'd make slightly more sense if it had you push to the project's repo (the PR refs), but oh well
270 2016-09-21T09:40:53  <wumpus> and it's not like it allows doing anything new, it was already possible to change a branch before merging it, by doing it locally
271 2016-09-21T09:41:01  <luke-jr> tempting to try opening a PR against both Core and Classic, and see if one can influence the other..
272 2016-09-21T09:41:34  <wumpus> luke-jr: yes. It'd make more sense if it was copy-on-write, and the branch changed to a local branch if a repo owner wants to override it
273 2016-09-21T09:42:37  <wumpus> luke-jr: hah
274 2016-09-21T09:43:07  <wumpus> that's a clever idea, but let's not do it in this case, we don't want more allegations of attacking classic
275 2016-09-21T09:44:35  <GitHub10> [bitcoin] luke-jr opened pull request #8772: [0.13] Backports (0.13...backports-0.13) https://github.com/bitcoin/bitcoin/pull/8772
276 2016-09-21T09:48:51  <GitHub137> [bitcoin] luke-jr opened pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (master...bugfix_link_20160921) https://github.com/bitcoin/bitcoin/pull/8773
277 2016-09-21T09:51:15  <MarcoFalke> wumpus: Can I get permission to merge doc changes (comments, markdown, ...)?
278 2016-09-21T09:53:42  <MarcoFalke> Otherwise I will just ping you when I feel soemthing trivial can be merged
279 2016-09-21T09:53:49  <GitHub124> [bitcoin] luke-jr opened pull request #8774: Qt refactors to better abstract wallet access (master...multiwallet_prefactor_qt) https://github.com/bitcoin/bitcoin/pull/8774
280 2016-09-21T09:57:07  <GitHub30> [bitcoin] luke-jr opened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
281 2016-09-21T09:58:20  *** Yogh has quit IRC
282 2016-09-21T09:59:06  *** Yogh has joined #bitcoin-core-dev
283 2016-09-21T10:01:19  <GitHub181> [bitcoin] luke-jr opened pull request #8776: Wallet refactoring leading up to multiwallet (master...multiwallet_prefactor_wallet) https://github.com/bitcoin/bitcoin/pull/8776
284 2016-09-21T10:01:52  <luke-jr> there we go, I think that's as far as I can go with split PRs until they get merged :p
285 2016-09-21T10:06:54  *** JackH has joined #bitcoin-core-dev
286 2016-09-21T10:25:04  <wumpus> MarcoFalke: sure
287 2016-09-21T10:28:14  <GitHub94> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/84c9a048559d...886e8c9b7269
288 2016-09-21T10:28:15  <GitHub94> bitcoin/master fab9107 MarcoFalke: init: Get rid of fDisableWallet
289 2016-09-21T10:28:15  <GitHub94> bitcoin/master fa58edb MarcoFalke: [wallet] Introduce DEFAULT_DISABLE_WALLET
290 2016-09-21T10:28:16  <GitHub94> bitcoin/master 886e8c9 Wladimir J. van der Laan: Merge #8768: init: Get rid of fDisableWallet...
291 2016-09-21T10:28:29  <GitHub81> [bitcoin] laanwj closed pull request #8768: init: Get rid of fDisableWallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8768
292 2016-09-21T10:29:56  <wumpus> MarcoFalke: certainly trivial things like https://github.com/bitcoin/bitcoin/pull/8773 you can just merge if they check out
293 2016-09-21T10:31:59  <GitHub109> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/886e8c9b7269...52b5a8785de7
294 2016-09-21T10:31:59  <GitHub109> bitcoin/master 6f933c6 Luke Dashjr: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
295 2016-09-21T10:32:00  <GitHub109> bitcoin/master 52b5a87 MarcoFalke: Merge #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
296 2016-09-21T10:32:09  <GitHub143> [bitcoin] MarcoFalke closed pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (master...bugfix_link_20160921) https://github.com/bitcoin/bitcoin/pull/8773
297 2016-09-21T10:33:02  <wumpus> re: wallet, I'd really like to get https://github.com/bitcoin/bitcoin/pull/7551 in
298 2016-09-21T10:33:15  <wumpus> I think it's even more important than multiwallet
299 2016-09-21T10:33:56  <wumpus> well it's pretty much orthagonal but okay
300 2016-09-21T10:34:50  <wumpus> as we can't get around allowing users to import things into the wallet, finally  having a consistent, one-stop call to import things into the wallet would help
301 2016-09-21T10:34:56  <sipa> wumpus: thabks for the reminder, eill review
302 2016-09-21T10:35:02  <sipa> *will
303 2016-09-21T10:35:05  <sipa> *thanks
304 2016-09-21T10:35:06  <wumpus> thanks
305 2016-09-21T10:38:44  <MarcoFalke> Sry, I think qt no longer compiles on master.
306 2016-09-21T10:39:03  <sipa> uh-oh
307 2016-09-21T10:39:09  <MarcoFalke> Forgot to #include wallet.h
308 2016-09-21T10:39:44  <MarcoFalke> the "introduce DEFAULT_DISABLE_WALLET" is more involved
309 2016-09-21T10:39:47  <MarcoFalke> in qt
310 2016-09-21T10:39:52  <MarcoFalke> than search and replace
311 2016-09-21T10:40:17  <MarcoFalke> might want to properly fix it, now that multiwallet is the goal
312 2016-09-21T10:42:54  *** laurentmt has joined #bitcoin-core-dev
313 2016-09-21T10:43:08  *** laurentmt has quit IRC
314 2016-09-21T10:47:54  <wumpus> let's first get it to compile again
315 2016-09-21T10:50:07  <sipa> *commits a #if 0 .. #endif around all .cpp files* - what did you do?! - it compiles again!
316 2016-09-21T10:50:27  <wumpus> hehe
317 2016-09-21T10:51:05  <wumpus> it's just that 'properly fix it' sounds like something that takes significant time, and I'm held up by this, maybe we should just revert that commit for now? @MarcoFalke
318 2016-09-21T10:52:00  <wumpus> then do it the proper way some other time
319 2016-09-21T10:52:12  <wumpus> re-do
320 2016-09-21T10:53:55  <MarcoFalke> wumpus: Will create a pull
321 2016-09-21T10:54:20  <wumpus> but if it involves multiwallet changes may be better to revert the current naive commit for now?
322 2016-09-21T10:54:55  <MarcoFalke> should work without multiwallet changes
323 2016-09-21T10:55:01  <MarcoFalke> Is this "Method names start with upper case" a style thing?
324 2016-09-21T10:55:04  <wumpus> e.g. just fa58edb not the other commitin that pull
325 2016-09-21T10:55:18  <wumpus> MarcoFalke: dunno, seems another satoshi-ism
326 2016-09-21T10:55:34  <MarcoFalke> I think we have half of the names start upper case and the other half don't
327 2016-09-21T10:55:42  <wumpus> qt code uses lowerCamelCase at least
328 2016-09-21T10:55:44  <MarcoFalke> Never sure what to use in fresh code
329 2016-09-21T10:55:55  <MarcoFalke> ok
330 2016-09-21T10:56:26  <wumpus> nah if you sak me for something new and independent I'd suggest using lowerCamelCase, that's a more common C++ naming convention
331 2016-09-21T10:56:36  <wumpus> if you change existing code just go with the style of that code
332 2016-09-21T10:56:57  <sipa> hmm, nearly all of the existing core code uses capitalized class and function names
333 2016-09-21T10:57:06  <sipa> so i'd rather not introduce something else
334 2016-09-21T10:57:36  <sipa> the developer notes used to mention this
335 2016-09-21T10:57:41  <wumpus> I really have no strong opinion on it
336 2016-09-21T10:57:56  <wumpus> I'm fine with either, but don't mix them in one class/unit
337 2016-09-21T10:58:39  <wumpus> especially with code I may use for other projects (such as the locked memory manager) I really prefer not to use this weird method capitalization style
338 2016-09-21T11:01:38  <wumpus> even c++11 has some assumptions about method and function names starting with lower-case, e.g. range-base for loops expect begin/end() not Begin/End()
339 2016-09-21T11:03:03  <wumpus> capitalizing class names, on the other hand, makes sense to keep them apart
340 2016-09-21T11:04:11  <sipa> all stl functions are lower_separated_by_underscore()
341 2016-09-21T11:04:30  <wumpus> yes, that's a valid choice too
342 2016-09-21T11:04:36  <wumpus> snake_case :)
343 2016-09-21T11:04:58  <sipa> i perdonally find lowerCaseFollowedByUpper very strange, but it's all highly subjective
344 2016-09-21T11:05:04  <wumpus> many projects use that for variables and member variables, that's reasonable sane
345 2016-09-21T11:07:21  <wumpus> for method names too, but using it for everything including class names well it's consistent but makes it hard to tell things apart
346 2016-09-21T11:08:02  <wumpus> unless you have an editor such as Qt Creator which highlights class names differently from methods differently from class variables, but I don't have that luxury since I switched to vim
347 2016-09-21T11:09:07  <wumpus> having a separate naming convention for classes also avoids creating a class with the same name as a function
348 2016-09-21T11:10:42  <wumpus> in any case I have no problems with stl-style either, except that it reminds me of boost :-)
349 2016-09-21T11:11:48  <GitHub122> [bitcoin] MarcoFalke opened pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
350 2016-09-21T11:13:12  <sipa> wumpus: i guess i'm biased because i learned c++ from bitcoin's codebase :)
351 2016-09-21T11:13:35  <sipa> well, i knew c++ from university, but that was purely theory without ajy software development experience
352 2016-09-21T11:14:42  <wumpus> yes, that can twist your mind :)
353 2016-09-21T11:15:35  <wumpus> MarcoFalke: I'm confused by #8777, why do we have a wallet model if the wallet is disabled
354 2016-09-21T11:15:50  <wumpus> did I really make it that way?
355 2016-09-21T11:16:13  <MarcoFalke> My method is static
356 2016-09-21T11:17:21  <wumpus> oh, okay, yes, that can work
357 2016-09-21T11:17:50  <MarcoFalke> I think there is no walletModel in case of -disablewallet=1
358 2016-09-21T11:18:01  <wumpus> static methods cover no instances, so can apply to all instances
359 2016-09-21T11:18:05  <wumpus> yes
360 2016-09-21T11:18:07  <wumpus> phew
361 2016-09-21T11:19:33  <wumpus> sipa: I think you learned c++ very well considering what you learned it from. Then again, I learned c++ from the MSVC6 manual and MS MFC stuff, so my initial influence is ever so malformed too.
362 2016-09-21T11:19:58  <sipa> wumpus: i did know C pretty well beforehand, maybe that helped :)
363 2016-09-21T11:21:10  <sipa> also, satoshi's c++ had a weird style, but it also did many things well, i think - hardly any manual memory management, no overuse of class hierarchies, some templating but only where it really avoids a ton of code, ...
364 2016-09-21T11:22:17  <wumpus> yes that's true, it has its positive sides. It's just that he was bad at isolating aspects from each other, and code organization.
365 2016-09-21T11:22:18  <MarcoFalke> So let's fetch some tea until travis clears the backlog
366 2016-09-21T11:23:34  <sipa> wumpus: /me still recalls the call to mark a key as used from inside the script validation code, wallet being in main.cpp, and direct calls into the wx code from inside block validation :)
367 2016-09-21T11:24:54  *** cryptapus has joined #bitcoin-core-dev
368 2016-09-21T11:27:47  <wumpus> sipa: hah!
369 2016-09-21T11:28:29  <wumpus> MarcoFalke: we could cancel all the preceeding builds as they're going to fail anyway
370 2016-09-21T11:30:29  <MarcoFalke> done. Should pick up the pull now
371 2016-09-21T11:31:33  <MarcoFalke> reminds me that no entry in the travis matrix has qt builds enabled
372 2016-09-21T11:31:57  <MarcoFalke> IIRC osx cross build does it (silently)
373 2016-09-21T11:32:02  <wumpus> that was disabled for *somereason cfields probably knows*
374 2016-09-21T11:32:14  <MarcoFalke> timeouts?
375 2016-09-21T11:32:30  <wumpus> possibly timeout-related back when there were problems with caching after the travis trusty switch
376 2016-09-21T11:32:40  <wumpus> yes
377 2016-09-21T11:34:14  <MarcoFalke> Also, I thought about switching to docker within travis, but then the travis script is already complicated and it won't get better/easier, as there are no dockerfiles for native osx and native win
378 2016-09-21T11:34:56  <wumpus> yea docker solves a problem we don't have, here
379 2016-09-21T11:35:15  <MarcoFalke> Was on an unrelated note  ;)
380 2016-09-21T11:35:31  *** murch has joined #bitcoin-core-dev
381 2016-09-21T11:35:59  <MarcoFalke> (travis has no plans to switch to xenial soon)
382 2016-09-21T11:36:06  <wumpus> testing native osx/win would be interesting, but I guess that runs into license issues
383 2016-09-21T11:36:26  <MarcoFalke> Oh, travis has native osx?
384 2016-09-21T11:36:49  <wumpus> and in the case of windows multi-stage issues: we want to build on trusty, then run the tests on an actualwindows machine
385 2016-09-21T11:37:46  <wumpus> though WINE is really convenient here and I have never seen any issues where wine didn't detect a problem that real windows would. WINE seems to be *stricter* in API correctness
386 2016-09-21T11:39:07  <MarcoFalke> (Right now we are bound to whatever ubuntu 14.04 provides us. Though, deterministic builds of the toolchain would help to untangle this)
387 2016-09-21T11:39:35  <wumpus> switching to xenial would be a disaster right now, esp for windows build
388 2016-09-21T11:40:28  <wumpus> I should likely put https://github.com/bitcoin/bitcoin/pull/8249 on ice; having less effective ASLR is great compared to the alternative of crashing with stack protectors :)
389 2016-09-21T11:40:30  <MarcoFalke> No one detected this. We should have run tests on xenial at least for the release
390 2016-09-21T11:40:50  <MarcoFalke> But then it is unfeasible to try every os and combination of toolchains
391 2016-09-21T11:41:06  <wumpus> well this is a cross build issue that didn't get detected
392 2016-09-21T11:41:11  <wumpus> we can't test every toolchain in existence
393 2016-09-21T11:41:22  <wumpus> right
394 2016-09-21T11:41:45  <wumpus> unfortunately, there are plenty of mingw toolchains that create absolutely broken windows code
395 2016-09-21T11:41:45  <MarcoFalke> So cfields work sounds like the right step
396 2016-09-21T11:41:56  <wumpus> we used to have that issue, and now it's back
397 2016-09-21T11:42:57  <MarcoFalke> Looks like travis likes my pull.
398 2016-09-21T11:43:12  * MarcoFalke off
399 2016-09-21T11:43:24  <wumpus> I wonder if switching to clang would help there. From what I've heard from some infosec related people the clang windows support is getting pretty good, and MSFT is even contributing to it. And Mozilla uses it to build Rust binaries (unsure if they use it for building firfox for windows)
400 2016-09-21T11:43:27  <wumpus> thanks ,going to merge it
401 2016-09-21T11:44:34  <wumpus> cfields: ^^ re clang and windows, should we consider that?
402 2016-09-21T11:45:07  <wumpus> would be worth an experiment at least I guess
403 2016-09-21T11:45:21  *** jchrome has joined #bitcoin-core-dev
404 2016-09-21T11:45:44  <GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/52b5a8785de7...fec6af744014
405 2016-09-21T11:45:44  <GitHub146> bitcoin/master 6666ca6 MarcoFalke: [qt] WalletModel: Expose disablewallet
406 2016-09-21T11:45:45  <GitHub146> bitcoin/master fec6af7 Wladimir J. van der Laan: Merge #8777: [qt] WalletModel: Expose disablewallet...
407 2016-09-21T11:45:58  <GitHub97> [bitcoin] laanwj closed pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
408 2016-09-21T11:57:38  *** PaulCapestany has quit IRC
409 2016-09-21T12:00:24  *** rubensayshi has quit IRC
410 2016-09-21T12:00:34  *** PaulCapestany has joined #bitcoin-core-dev
411 2016-09-21T12:01:06  *** jchrome has quit IRC
412 2016-09-21T12:06:09  *** PaulCapestany has quit IRC
413 2016-09-21T12:06:54  *** jchrome has joined #bitcoin-core-dev
414 2016-09-21T12:14:05  <GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fec6af744014...cf5ebaa921a9
415 2016-09-21T12:14:06  <GitHub170> bitcoin/master 7c069a7 Pavel Janík: Do not shadow global variable
416 2016-09-21T12:14:06  <GitHub170> bitcoin/master cf5ebaa Wladimir J. van der Laan: Merge #8656: Trivial: Do not shadow global variable fileout...
417 2016-09-21T12:14:15  <GitHub191> [bitcoin] laanwj closed pull request #8656: Trivial: Do not shadow global variable fileout (master...20160902_Wshadow_fileout) https://github.com/bitcoin/bitcoin/pull/8656
418 2016-09-21T12:16:33  *** Alina-malina has quit IRC
419 2016-09-21T12:16:55  *** jchrome has quit IRC
420 2016-09-21T12:21:18  *** Alina-malina has joined #bitcoin-core-dev
421 2016-09-21T12:23:11  *** jchrome has joined #bitcoin-core-dev
422 2016-09-21T12:24:56  *** Alina-malina has quit IRC
423 2016-09-21T12:24:56  *** Alina-malina has joined #bitcoin-core-dev
424 2016-09-21T12:27:02  *** cryptapus_ has joined #bitcoin-core-dev
425 2016-09-21T12:29:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
426 2016-09-21T12:31:16  *** cryptapus has quit IRC
427 2016-09-21T12:35:24  *** jchrome has quit IRC
428 2016-09-21T12:44:04  <wumpus> jonasschnelli: btw I registered for http://coredev.tech/nextmeeting_tmp.html some time ago but my name is not appearing yet, did something go wrong?
429 2016-09-21T12:44:50  <sipa> wumpus: you're on http://coredev.tech/nextmeeting.html ?
430 2016-09-21T12:45:04  <wumpus> oh I have the wrong link, okay
431 2016-09-21T12:45:16  <wumpus> yep
432 2016-09-21T12:50:20  <GitHub78> [bitcoin] MarcoFalke closed pull request #8536: [qa] Adjust poll interval for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536
433 2016-09-21T12:50:57  <jonasschnelli> wumpus: Yes. Your listed... need to remove the *_tmp.html files!
434 2016-09-21T12:51:12  <jonasschnelli> I updated the page right after you submitted your form. :)
435 2016-09-21T12:52:06  <jonasschnelli> Ah. instagibbs just submitted the form as well...
436 2016-09-21T12:52:47  <instagibbs> i saw it being discussed here
437 2016-09-21T12:53:44  * jonasschnelli didn't know that wumpus is in the plubming business. .. :)
438 2016-09-21T12:54:35  <jonasschnelli> *plumbing
439 2016-09-21T12:55:04  *** cryptapus_ is now known as cryptapus
440 2016-09-21T13:05:01  *** Chris_Stewart_5 has quit IRC
441 2016-09-21T13:06:26  <MarcoFalke> jonasschnelli: I think you forgot to merge the overlay pull this morning :)
442 2016-09-21T13:07:50  <jonasschnelli> MarcoFalke: I was hoping someone did another review,.. but will merge in the next couple of hours.
443 2016-09-21T13:08:02  <jonasschnelli> *someone will do
444 2016-09-21T13:08:43  <BlueMatt> luke-jr: they seem to have partially fixed the email issues
445 2016-09-21T13:08:45  <BlueMatt> github, that is
446 2016-09-21T13:09:02  <BlueMatt> as of yesterday i was still getting duplicate emails from them, but at least they're properly threaded
447 2016-09-21T13:10:42  <jonasschnelli> BlueMatt: while your here.. :), do you use the contrib/debian packaging dir for your bitcoin PPA?
448 2016-09-21T13:11:10  <BlueMatt> i forked off of it a while ago, but anything something gets updated in contrib/debian i re-sync it
449 2016-09-21T13:11:29  <BlueMatt> iirc the only real difference is package description (the new one is pretty terrible, iirc) and changelog
450 2016-09-21T13:11:44  <BlueMatt> new as of like 3 versions ago, that is
451 2016-09-21T13:12:28  <jonasschnelli> BlueMatt: I guess we should add zmq to the dependencies
452 2016-09-21T13:12:46  <jonasschnelli> which probably should result compiling with zmq
453 2016-09-21T13:12:56  <BlueMatt> oh, thats another difference - upnp is not built-in
454 2016-09-21T13:13:06  <BlueMatt> because of the security issues a while back, and i never re-added it
455 2016-09-21T13:13:06  <jonasschnelli> otherwise our "official" binary comes with zmq while the PPA does not
456 2016-09-21T13:13:11  <BlueMatt> but no one has complained, so whatever
457 2016-09-21T13:13:25  <BlueMatt> yea, could add zmq, though also security-swiss-cheese
458 2016-09-21T13:13:33  <BlueMatt> but maybe i should....
459 2016-09-21T13:14:00  <jonasschnelli> I would argue that if you like to use ZMQ, you should self-compile... but, yeah...
460 2016-09-21T13:14:42  <BlueMatt> i mean ive never heard any complaints about that or upnp
461 2016-09-21T13:15:02  <wumpus> zmq is only used for notification, and disabled by default
462 2016-09-21T13:15:09  <BlueMatt> (not that that indicates much, people like to keep complaints to themselves, mostly)
463 2016-09-21T13:15:28  <BlueMatt> wumpus: I'm aware, but so is upnp in bitcoind, and its still gross :p
464 2016-09-21T13:16:02  <BlueMatt> though i did actually get like 2/3 emails about the 12.04 empty-package update, which i found impressive
465 2016-09-21T13:16:08  <wumpus> yes, it's up to you as maintainer, please do explain that in the issue
466 2016-09-21T13:16:47  <BlueMatt> hmm? was an issue opened for this? sorry, I havent checked github emails in a day, I'll get caught up on github when I'm done with breakfast
467 2016-09-21T13:16:48  <wumpus> people really shouldn't complain to us about the PPAs, though i guess the ppa doesn't have its own issue tracker
468 2016-09-21T13:16:56  <wumpus> yes there's an issue, let em see
469 2016-09-21T13:17:12  <sipa> BlueMatt: a few people in #bitcoin were confused by bitcoind disappearing
470 2016-09-21T13:17:13  <jonasschnelli> we have contrib/debian though
471 2016-09-21T13:17:34  <BlueMatt> oh, well if someone complained I can add it
472 2016-09-21T13:17:45  <BlueMatt> sipa: yea, if i get emails then #bitcoin is generally guaranteed to complain
473 2016-09-21T13:17:49  <BlueMatt> not much i could do, though :/
474 2016-09-21T13:17:58  <sipa> BlueMatt: maybe a #!/bin/sh echo "The Bitcoin Core PPA no longer supports Ubuntu 12.04" would be better than just empty package?
475 2016-09-21T13:18:29  <wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/issues/8759
476 2016-09-21T13:18:32  <BlueMatt> i was later informed that you can make the updater pop up the package changelog during the update process so people have to read it, though i assume the gui tools might hide it
477 2016-09-21T13:18:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
478 2016-09-21T13:18:55  <wumpus> BlueMatt: yes, I've seen that only once, the GUI tools do show it
479 2016-09-21T13:19:20  <wumpus> it's meant for really critical notifications regarding a package, I guess this qualifies
480 2016-09-21T13:19:37  <BlueMatt> indeed
481 2016-09-21T13:21:32  <wumpus> btw re: github mails I found out that it's possible to filter mails where you're personally notified from the rest of the bulk by filtering for "to:mention@noreply.github.com", may be useful
482 2016-09-21T13:22:15  * BlueMatt ponders maildrop rule therefor
483 2016-09-21T13:22:21  <wumpus> I started receiving so many github mails that that's the only ones I read at at the moment
484 2016-09-21T13:23:22  <wumpus> (of course I tend to read the rest, but on github.com, not in my mailbox)
485 2016-09-21T13:25:16  <wumpus> in any case please comment on #8759. I don't mind personally whether you want to support zmq or not, but the decision should be documented
486 2016-09-21T13:26:21  <wumpus> jonasschnelli: at least the manpages will be gone from there now
487 2016-09-21T13:28:36  <BlueMatt> wumpus: yep, still eating breakfast, give me a few :p
488 2016-09-21T13:29:03  <wumpus> BlueMatt: yes I don't mean to hurry :p
489 2016-09-21T13:32:57  <wumpus> re: the new github review system, is it possible to un-approve a pull?
490 2016-09-21T13:34:06  *** Chris_Stewart_5 has quit IRC
491 2016-09-21T13:40:35  *** PaulCapestany has joined #bitcoin-core-dev
492 2016-09-21T13:40:48  *** DigiByteDev has quit IRC
493 2016-09-21T13:41:35  *** DigiByteDev has joined #bitcoin-core-dev
494 2016-09-21T13:47:06  *** PaulCapestany has quit IRC
495 2016-09-21T13:48:56  *** PaulCapestany has joined #bitcoin-core-dev
496 2016-09-21T13:53:39  *** aalex has joined #bitcoin-core-dev
497 2016-09-21T13:53:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
498 2016-09-21T14:05:05  *** DigiByteDev has quit IRC
499 2016-09-21T14:05:15  *** DigiByteDev_ has joined #bitcoin-core-dev
500 2016-09-21T14:22:12  *** xinxi has joined #bitcoin-core-dev
501 2016-09-21T14:23:05  <xinxi> Hi guys, are any documents on how to add a new type of address?
502 2016-09-21T14:23:51  *** DigiByteDev_ has quit IRC
503 2016-09-21T14:24:29  <xinxi> For example, if I want to use public key directly as the address using of using hash160, what should I do given that we don't care about quantum resistance?
504 2016-09-21T14:28:59  *** xinxi has quit IRC
505 2016-09-21T14:31:45  *** xinxi has joined #bitcoin-core-dev
506 2016-09-21T14:40:30  *** veleiro has joined #bitcoin-core-dev
507 2016-09-21T14:41:52  *** cryptapus has quit IRC
508 2016-09-21T14:42:07  *** paveljanik has joined #bitcoin-core-dev
509 2016-09-21T14:42:07  *** paveljanik has joined #bitcoin-core-dev
510 2016-09-21T14:42:19  *** cryptapus has joined #bitcoin-core-dev
511 2016-09-21T14:42:43  <instagibbs> murch: I'd be interested to see what effect, if any, witness discounting would have on effective paid fees per algorithm
512 2016-09-21T14:44:11  <murch> instagibbs: Lemme have a look at the results
513 2016-09-21T14:51:38  *** bsm117532 has quit IRC
514 2016-09-21T14:52:11  *** bsm117532 has joined #bitcoin-core-dev
515 2016-09-21T14:54:07  <murch> instagibbs: Fees are almost exactly halved through the bench.
516 2016-09-21T14:54:25  <murch> https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
517 2016-09-21T14:55:02  <murch> instagibbs: I've uploaded the whole output table here ^
518 2016-09-21T14:55:40  <sipa> murch: do any of the algorithms behave significantly better/worse (in terms of average number of transaction inputs) with and without segwit?
519 2016-09-21T14:55:54  <sipa> or number of utxos held
520 2016-09-21T14:59:56  <murch> sipa: Good question. Actually, Core seems to have a significantly increased average UtxoPool size. With P2WPKH it's 70% bigger (×1.7). Only Core significantly changes though.
521 2016-09-21T15:01:39  <murch> Input set size has also a much bigger deviation for Core under P2WPKH. I'm weirded out by that though. I'll have to check whether that is reproducable.
522 2016-09-21T15:03:57  <instagibbs> murch: are total fees in satoshis or?
523 2016-09-21T15:04:05  <murch> instagibbs: Yes.
524 2016-09-21T15:04:59  <murch> instagibbs: All bitcoin values are in satoshi.
525 2016-09-21T15:07:12  *** Giszmo has quit IRC
526 2016-09-21T15:11:34  *** aalex has quit IRC
527 2016-09-21T15:11:52  *** Giszmo has joined #bitcoin-core-dev
528 2016-09-21T15:13:26  *** aalex has joined #bitcoin-core-dev
529 2016-09-21T15:16:32  *** skyraider has joined #bitcoin-core-dev
530 2016-09-21T15:19:08  *** d4de has joined #bitcoin-core-dev
531 2016-09-21T15:19:38  <skyraider> hi, i'm getting some odd bitcoind errors on startup - the tor disconnect callback seems to be firing, but i have nothing about tor in my config file
532 2016-09-21T15:19:57  <skyraider> https://www.irccloud.com/pastebin/rENd1qLg/tor%20disconnect%20callback%20incorrectly%20firing%20on%200.13.0
533 2016-09-21T15:20:12  <d4de> I was surprised today by a bunch of tor client messages in our systems. Why not SOCKS5?
534 2016-09-21T15:20:39  <sipa> skyraider: it's just trying to reach the tor control port to open a socket
535 2016-09-21T15:20:49  <skyraider> (for additional context, this pull request supposedly fixes that message, but apparently not https://github.com/bitcoin/bitcoin/pull/7637)
536 2016-09-21T15:20:52  <sipa> it's enabled by default, but doesn't do anything if you don't have tor running
537 2016-09-21T15:21:02  <skyraider> sipa: ah, so it's harmless?
538 2016-09-21T15:21:17  <sipa> yes
539 2016-09-21T15:21:21  <skyraider> thanks
540 2016-09-21T15:21:31  <sipa> that PR just prevents it from spamming your debug.log all the time
541 2016-09-21T15:21:36  <sipa> now it just mentions it onc
542 2016-09-21T15:21:38  <sipa> *once
543 2016-09-21T15:22:47  <sipa> you can disable it by setting listenonion=0 in bitcoin.conf
544 2016-09-21T15:22:53  <sipa> or running with -nolistenonion
545 2016-09-21T15:25:41  <skyraider> hmm, i received several warnings... 6, it seems
546 2016-09-21T15:28:32  <sipa> that's unexpected
547 2016-09-21T15:28:47  <skyraider> listenonion=0 is effective, though. no warning after applying that config setting.
548 2016-09-21T15:35:33  *** Sosumi has joined #bitcoin-core-dev
549 2016-09-21T15:46:48  *** JackH has quit IRC
550 2016-09-21T16:08:58  <gmaxwell> murch: is your 'corewallet' with or without the extra input removal?
551 2016-09-21T16:09:16  <murch> gmaxwell: Without pruning
552 2016-09-21T16:09:23  <murch> i.e. extra input removal
553 2016-09-21T16:09:39  <gmaxwell> okay
554 2016-09-21T16:11:51  <murch> gmaxwell: That's actually the only difference between BreadWallet and Mycelium: Both do FIFO and Mycelium additionally minimizes the input set by removing extra inputs. As you see, it has a huge impact on the mean Utxo set size.
555 2016-09-21T16:13:35  <murch> gmaxwell: You might also find this table with more evaluation criteria interesting: https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml (same as posted above)
556 2016-09-21T16:14:07  <gmaxwell> how do the wallets doing fifo handle it if they get dustspammed? (someone pays them more tiny inputs than they can fit in a single txn?)
557 2016-09-21T16:16:23  <BlueMatt> murch: in your analysis, I'm assuming AndroidWallet is just the old bitcoinj code I wrote many years ago and not something AndroidWallet specific?
558 2016-09-21T16:16:44  <murch> BlueMatt: Yes, it's the coin selector from BitcoinJ.
559 2016-09-21T16:16:57  <gmaxwell> BlueMatt: the paper says it uses "value * inputAge"
560 2016-09-21T16:17:10  <BlueMatt> gmaxwell: it was written when using priority as selection wasnt insane :p
561 2016-09-21T16:17:22  <BlueMatt> murch: is your "fee spent" thing just tx size * fee something, or does it actually analyze the code's fee selection behavior?
562 2016-09-21T16:18:12  <BlueMatt> murch: have you tested the bitcoinj thing with a coinselector which does something smarter (like picking smallest-bigger-than-desired) even if its dead-simple?
563 2016-09-21T16:18:18  <murch> gmaxwell: In their selector I didn't see any special checks for small inputs, they may have checks in their utxo pool management though. I didn't check that.
564 2016-09-21T16:18:36  <murch> BlueMatt: It uses a flat fee of 10 satoshi per byte.
565 2016-09-21T16:18:53  <BlueMatt> murch: ok, cool, yea, so it generates the smallest total tx bytes
566 2016-09-21T16:20:03  <murch> BlueMatt: I added block height to the UTXO in order to give the BitcoinJ coin selector a better chance (instead of just selecting the largest always). My time model is very simple though and just jumps Gaussian time steps between transactions.
567 2016-09-21T16:20:30  <murch> BlueMatt: Unfortunately, my scenario data does not contain actual time information.
568 2016-09-21T16:21:14  <BlueMatt> murch: i mean the bitcoinj thing is now braindead as fuck...it made sense way back when it was written but the fact that it hasnt been updated since is surpsiing to me, because thats insane
569 2016-09-21T16:21:51  <murch> BlueMatt: I have not checked just selecting "smallest bigger" yet. I just replicated what I found in the code.
570 2016-09-21T16:23:07  <gmaxwell> BlueMatt: you mean making the final utxo set 126 times larger than bitcoin core isn't good?
571 2016-09-21T16:23:44  <BlueMatt> murch: wait, did you take the like overcomplicated thing in the wallet that tries to figure out if change is reasonable, or just do the priority-based selection
572 2016-09-21T16:23:45  <murch> BlueMatt: Perhaps there is a misunderstanding here: I have just replicated the coin selection behavior. I have also replicated fee estimation to the point that some wallets will always assume a change output and pay for it. I have not replicated how fee levels are estimated for each wallet.
573 2016-09-21T16:24:20  <BlueMatt> gmaxwell: i mean now its essentially just randomly selecting shit...like ignore that its making the utxo set larger its just like selecting things almost randomly because it hasnt been updated to realize that priority hasnt been a thing for a year or two now
574 2016-09-21T16:25:03  <BlueMatt> murch: did you emulate public FeeCalculation calculateFee(SendRequest req, Coin value, List<TransactionInput> originalInputs,
575 2016-09-21T16:25:03  <BlueMatt>                                        boolean needAtLeastReferenceFee, List<TransactionOutput> candidates) throws InsufficientMoneyException {
576 2016-09-21T16:25:04  <BlueMatt> ?
577 2016-09-21T16:25:25  <BlueMatt> I mean because that is, essentially, the actual coin selection algorithm, not just CoinSelector
578 2016-09-21T16:26:42  <murch> BlueMatt: Having a look, sorry it's been a few weeks
579 2016-09-21T16:26:47  <BlueMatt> yea, np
580 2016-09-21T16:27:14  *** xinxi has quit IRC
581 2016-09-21T16:27:34  <BlueMatt> god this code is soooo old
582 2016-09-21T16:27:42  <BlueMatt> wow, does no one maintain bitcoinj at all? how was this not replaced
583 2016-09-21T16:30:02  <instagibbs> murch: i think you should try to control for estimated fees as much as possible. Hard to disentagle fees vs utxos with current data
584 2016-09-21T16:30:19  <gmaxwell> murch: so is your codebase in a position to try more hypothetical algorithims?
585 2016-09-21T16:31:32  <murch> BlueMatt: I had missed "calculateFee", I had only discovered the CoinSelector.
586 2016-09-21T16:32:13  <BlueMatt> murch: oh shit, that will probably significantly effect your simulation
587 2016-09-21T16:32:34  <murch> gmaxwell: I was planning to provide it around Scaling Bitcoin. There was a few more things I wanted to do before publishing it. Trying other strategies is a case of inheritance and overriding a single function though.
588 2016-09-21T16:33:17  *** jchrome has joined #bitcoin-core-dev
589 2016-09-21T16:33:28  <murch> BlueMatt: I should have written to the mailing list earlier. (._.)
590 2016-09-21T16:33:52  <BlueMatt> murch: well either way you re-confirmed what we all knew: bitcoinj is unmaintained and its use should be significantly discouraged
591 2016-09-21T16:34:44  *** xinxi has joined #bitcoin-core-dev
592 2016-09-21T16:35:04  <murch> BlueMatt: Is it as complex as it looks. Could you walk me through how it influences Coin Selection from the top of your head, if it isn't too complicated?
593 2016-09-21T16:36:11  <murch> instagibbs: I was actually just looking at Coin Selection strategies and had in the beginning completely avoided fee estimation. I added fees after I realized how deeply ingrained fee estimation was in Core's coin selection.
594 2016-09-21T16:36:41  <murch> Seems like I'm misrepresenting BitcoinJ here then.
595 2016-09-21T16:36:58  <murch> perhaps also the other wallets.
596 2016-09-21T16:37:51  <BlueMatt> murch: hmmm, i cant say i recall exactly what the behavior there is...its also very much based on what bitcoin core did at the time (and its non-fee anti-spam measures)
597 2016-09-21T16:38:01  <BlueMatt> murch: is your simulator in java? that code is very standalone
598 2016-09-21T16:38:15  <sipa> i don't understand why fee estimation matters
599 2016-09-21T16:38:16  <murch> BlueMatt: Scala actually.
600 2016-09-21T16:38:37  <BlueMatt> sipa: its not really fee estimation, its the thing that selects between coin selection options and change
601 2016-09-21T16:38:41  <BlueMatt> ie whether to throw away change
602 2016-09-21T16:38:58  <sipa> for a comparable simulation across clients you should assume a constant approximate feerate on the network
603 2016-09-21T16:39:01  <BlueMatt> murch: so you can just drop that function in, mostly? I actually have no idea about scala tooling
604 2016-09-21T16:39:09  <murch> sipa: E.g. Bitcoin Core uses an initial guess of the fee to restrict solutions in the selection pass through. It will only update the fee guess after the selection attempt if it didn't produce a satisfying result.
605 2016-09-21T16:39:10  <BlueMatt> sipa: he does that
606 2016-09-21T16:39:15  <sipa> and use the same fees in multiple tools
607 2016-09-21T16:39:36  <sipa> murch: ah! you mean fee estimation of the transaction you are creating
608 2016-09-21T16:39:42  <sipa> not feerate estimation on the network
609 2016-09-21T16:40:48  <murch> sipa: I did assume a constant fee rate of 10 satoshi per byte. There are some minor differences how wallets apply it though. (E.g. some always pay for a change output.)
610 2016-09-21T16:41:49  <murch> BlueMatt: Scala can call any Java class. But I'm a bit confused at this point: Does the calculateFee code just check whether to drop the change or create it, or does it change the actual selection?
611 2016-09-21T16:42:08  *** xinxi has quit IRC
612 2016-09-21T16:42:20  *** jchrome has quit IRC
613 2016-09-21T16:42:29  <BlueMatt> murch: it takes the CoinSelector and will call it three times, and select between the options based on what the resulting change is
614 2016-09-21T16:43:01  *** xinxi has joined #bitcoin-core-dev
615 2016-09-21T16:43:13  <murch> BlueMatt: o.0 I had the impression that the CoinSelector is deterministic?!
616 2016-09-21T16:44:59  <BlueMatt> i dont recall 100% how it works, iirc its something like "first call with the amount you need, then, if you got a change value which you were gonna throw away, call it again with enough additional to not throw away the change, and then there is a third case that does X"
617 2016-09-21T16:46:19  <murch> sipa: I should probably stress that my simulation does not cover fee levels. I've just applied a common fee estimation to all wallets that prescibes 10 satoshi per byte. The figures for the fees in my results are therefore essentially an abstraction of "inputs spent", "outputs created" and "changes created".
618 2016-09-21T16:47:08  <sipa> murch: that seems desirable to me
619 2016-09-21T16:47:09  <murch> BlueMatt: Ah, thanks. Now I get what you meant. I should probably be able to replicate that no problem.
620 2016-09-21T16:47:15  <sipa> (the way you do it)
621 2016-09-21T16:47:38  <sipa> otherwise there is the added variance of how wallets determine fees
622 2016-09-21T16:48:38  <murch> sipa: Yeah, and it would have also blown the overhead for my simulation out of proportion. I'll add it to "Future Work". ;)
623 2016-09-21T16:50:44  <murch> gmaxwell: Did you have something in particular in mind to try? We (sipa, you, instagibbs, me) did discuss this a few months ago already though. And I've also read your Bitcoin Wiki page on Coin Selection. :)
624 2016-09-21T16:55:50  * murch will be back after dinner
625 2016-09-21T17:02:11  <gmaxwell> murch: 10sat/byte or per weight? (how does the segwit analysis change it?)
626 2016-09-21T17:05:04  <gmaxwell> murch: so are you not modling the behavior where very small change out is converted into fee to avoid creating change?
627 2016-09-21T17:13:39  <xinxi> gmaxwell: CT uses ECDH, which is not quantum resistant. Why not use a quantum resistant key exchange crypto algorithm?
628 2016-09-21T17:14:19  <instagibbs> xinxi: maybe #bitcoin-wizards ?
629 2016-09-21T17:14:54  <xinxi> instagibbs: what's that for?
630 2016-09-21T17:15:27  <instagibbs> this channel is for near-term bitcoin core development, your question is about an implementation of elements sidechain and/or future quantum advances
631 2016-09-21T17:15:35  <instagibbs> that channel is more suitable
632 2016-09-21T17:15:44  <xinxi> instagibbs: OK.
633 2016-09-21T17:15:56  <instagibbs> I can answer you there
634 2016-09-21T17:18:57  <GitHub24> [bitcoin] MarcoFalke opened pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
635 2016-09-21T17:28:02  <gmaxwell> murch: as far as changes, there are a number of simple strategies I'd try.  E.g. try to form a zero change transaction, converting up to X to extra fees,  failing that, add a change output, and spend all coins paid to a selected address when any are spent.  If change >2x the payment, create two change outputs, randomly selecting splitting the change in half or making one equal to the payment.
636 2016-09-21T18:14:43  *** harrymm has quit IRC
637 2016-09-21T18:22:52  *** skyraider has quit IRC
638 2016-09-21T18:48:35  *** Guyver2 has joined #bitcoin-core-dev
639 2016-09-21T18:52:29  <GitHub54> [bitcoin] MarcoFalke opened pull request #8780: [rpc] Deprecate getinfo (master...Mf1609-getinfoDeprecate) https://github.com/bitcoin/bitcoin/pull/8780
640 2016-09-21T18:54:14  *** davec has quit IRC
641 2016-09-21T18:55:06  *** davec has joined #bitcoin-core-dev
642 2016-09-21T19:00:24  *** xinxi has quit IRC
643 2016-09-21T19:02:03  *** xinxi has joined #bitcoin-core-dev
644 2016-09-21T19:02:05  <gmaxwell> MarcoFalke: please include more explination in your commit messages (/pull requs); e.g. the getinfo deprecate should give the short reason for it (replaced by rpc x/y/z)
645 2016-09-21T19:04:38  <gmaxwell> jonasschnelli: on the sweep thing (#8763); I agree the functionality would be useful. But I'm somewhat torn-- we really should be avoiding introducing pruning incompatible functionality, and right now recan is so slow as to be more or less useless.
646 2016-09-21T19:07:00  *** xinxi has quit IRC
647 2016-09-21T19:07:04  <gmaxwell> I suppose a sweep could instead work from the utxo set without loss.
648 2016-09-21T19:13:19  *** [Author] has quit IRC
649 2016-09-21T19:15:36  *** jtimon has quit IRC
650 2016-09-21T19:26:30  *** murch1 has joined #bitcoin-core-dev
651 2016-09-21T19:27:30  *** murch has quit IRC
652 2016-09-21T19:34:40  *** harrymm has joined #bitcoin-core-dev
653 2016-09-21T19:45:42  *** instagibbs has quit IRC
654 2016-09-21T19:46:01  *** cdecker has joined #bitcoin-core-dev
655 2016-09-21T19:46:47  <GitHub125> [bitcoin] MarcoFalke opened pull request #8781: [contrib] delete qt_translations.py (master...Mf1609-deleteQtTrans) https://github.com/bitcoin/bitcoin/pull/8781
656 2016-09-21T19:49:01  <MarcoFalke> I am looking for stuff but can only find outdated crap...
657 2016-09-21T19:54:59  *** Guyver2 has quit IRC
658 2016-09-21T20:02:18  *** Chris_Stewart_5 has quit IRC
659 2016-09-21T20:03:20  *** xinxi has joined #bitcoin-core-dev
660 2016-09-21T20:04:41  *** cryptapus has quit IRC
661 2016-09-21T20:10:31  *** jnewbery has joined #bitcoin-core-dev
662 2016-09-21T20:10:33  *** xinxi has quit IRC
663 2016-09-21T20:20:06  *** instagibbs has joined #bitcoin-core-dev
664 2016-09-21T20:26:45  *** jnewbery has quit IRC
665 2016-09-21T20:30:47  *** jl2012 has quit IRC
666 2016-09-21T20:44:44  *** crudel has quit IRC
667 2016-09-21T20:57:41  *** laurentmt has joined #bitcoin-core-dev
668 2016-09-21T21:07:46  *** xinxi has joined #bitcoin-core-dev
669 2016-09-21T21:08:31  *** jnewbery has joined #bitcoin-core-dev
670 2016-09-21T21:10:02  *** laurentmt has quit IRC
671 2016-09-21T21:14:16  *** xinxi has quit IRC
672 2016-09-21T21:22:08  <BlueMatt> <instagibbs> pfrom->GetLocalServices() & NODE_WITNESS && (nCMPCTBLOCKVersion == 2)
673 2016-09-21T21:22:09  <BlueMatt> <instagibbs> pfrom is referring to the remote node's flags, I hope
674 2016-09-21T21:22:11  <BlueMatt> ...
675 2016-09-21T21:22:19  <BlueMatt> <BlueMatt> I think nLocalServices refers to YOUR services
676 2016-09-21T21:22:22  <instagibbs> apparently not we learned, which confused the hell out of me
677 2016-09-21T21:22:26  <BlueMatt> <BlueMatt> and you store it in every CNode object
678 2016-09-21T21:22:28  <BlueMatt> is that true?
679 2016-09-21T21:22:31  <BlueMatt> that seems...fun?
680 2016-09-21T21:22:45  <instagibbs> nServices is the remote's services
681 2016-09-21T21:22:57  <sipa> will check
682 2016-09-21T21:22:59  <instagibbs> but both are stored on CNode
683 2016-09-21T21:22:59  <BlueMatt> seems like an easy optimization for cfields to fix?
684 2016-09-21T21:24:13  <instagibbs> well it could be a way to remember which services you promised without reconnecting?
685 2016-09-21T21:24:40  <instagibbs> ie remembering what other node will have for nExpectedServices
686 2016-09-21T21:25:55  <luke-jr> irssi exploit: https://irssi.org/security/irssi_sa_2016.txt (seems like a repeat of CVE-2003-1020, so may wish to consider whether there might be more unfound exploits..)
687 2016-09-21T21:26:32  <sipa> BlueMatt: i believe it was done because nLocalServices can change - by copying it into the CNode we have an immutable value that never changes, and also tells us what local services we announced to that peer
688 2016-09-21T21:28:02  <BlueMatt> ahh, i guess it doesnt change now, but we might decide to change the way we handle things in the future and then it could change?
689 2016-09-21T21:28:10  <BlueMatt> (I'm not aware of any way it could change in the current code?)
690 2016-09-21T21:28:21  <BlueMatt> eg pruning/bloom/etc cannot be turned on and off at runtime
691 2016-09-21T21:28:27  <sipa> agree, it's always set at startup
692 2016-09-21T21:28:28  <instagibbs> mind if i put a comment on that field to make that explicit? Maybe fewer tears in future
693 2016-09-21T21:28:42  <BlueMatt> please do
694 2016-09-21T21:28:52  <sipa> i'm making hypotheses here, cfields should probably comment
695 2016-09-21T21:29:04  <BlueMatt> i dont think its new/changed in CConMan
696 2016-09-21T21:29:07  <instagibbs> that was mine as well, but I'll wait for "official" call
697 2016-09-21T21:30:06  <sipa> BlueMatt: before connman nLocalServices was a global
698 2016-09-21T21:32:30  <instagibbs> I have a feeling reviewing cb pull will make a lot more sense now
699 2016-09-21T21:47:43  <murch1> gmaxwell: 10 sat per byte, and for P2WPKH 10 byte per weight (if that's bytes + byte/4 for the witness part)
700 2016-09-21T21:48:39  <murch1> gmaxwell: I have a MIN_CHANGE parameter, which for some wallets is the limit for conversion to fee and for other wallets (such as Core) added to the target before selection.
701 2016-09-21T21:49:47  <sipa> murch1: sounds right
702 2016-09-21T21:51:14  <gmaxwell> murch1: does your model for core convert dust to fees?
703 2016-09-21T21:56:06  <murch1> gmaxwell: Concerning the strategy, what is X? What would X be? The fee cost of the change output? My simulation doesn't model "addresses", so I can't model issues concerning address reuse. Address reuse is already heavily discouraged and I've decided to omit that. Change splitting is clear.
704 2016-09-21T21:56:47  <gmaxwell> ::sigh::
705 2016-09-21T21:57:05  <gmaxwell> murch1: okay, well your efforts then are moving things into a realm of academic novelty rather than anything pratical then.
706 2016-09-21T21:57:24  <sipa> gmaxwell, murch1: i believe you are misunderstanding each other
707 2016-09-21T21:58:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
708 2016-09-21T21:58:18  <gmaxwell> because address reuse is _very_ common on the network, and agressively consuming inputs is probably a good strategy-- but it's potentially devistating to privacy, but not if it's limited to same-address ... in which case it's probably helpful for privacy.
709 2016-09-21T21:58:53  <sipa> how is the rule to convert dust to fees at all related to address reuse?
710 2016-09-21T21:59:27  <gmaxwell> sipa: murch1 was responding to my earlier comment, not the most recent question about dust->fees..
711 2016-09-21T21:59:33  <sipa> ah
712 2016-09-21T22:01:38  <sipa> gmaxwell: he is currently moddelling how actual wallets work... that seems very practically useful and not an academic novelty
713 2016-09-21T22:02:13  <sipa> sure, if we're trying to find an optimal strategy, it may be worth taking reuse into account
714 2016-09-21T22:02:23  *** jtimon has joined #bitcoin-core-dev
715 2016-09-21T22:04:34  <murch1> gmaxwell: dust to fees: Yes it does, but only if it cannot create a direct match or a change of at least 0.01 BTC. In my simulation the smallest change Core created was 0.01 BTC.
716 2016-09-21T22:04:58  <sipa> i believe that's correct
717 2016-09-21T22:05:52  <sipa> (though we may want to reduce that value - there has been talk about making it based on the dust rule, derived from the mempool feerate or estimated feerate, but the current code is still 0.01 BTC i think)
718 2016-09-21T22:06:01  *** Yogh has quit IRC
719 2016-09-21T22:06:08  <gmaxwell> I'd be interested in knowing how the results change if it will send dust to fees more agressively.
720 2016-09-21T22:06:17  <sipa> yup
721 2016-09-21T22:06:39  <sipa> it's already pretty aggressive
722 2016-09-21T22:06:46  <gmaxwell> e.g. try a direct match, send dust change to fees. Only try targeting 0.01 btc change if that fails.
723 2016-09-21T22:07:33  <murch1> gmaxwell: Here is a question. For a very long time I thought that spending several outputs from the same address required only one signature. I recently saw an answer on Bitcoin.SE that said that spending transactions from the same address still uses a full signature each. Is the only concern privacy then?
724 2016-09-21T22:07:42  <gmaxwell> Sorry for sounding harsh above, it's demoralizing though to hear that you've done all this modling work and it can't model the behavior I suggested on the input pruning PR.
725 2016-09-21T22:08:15  *** Yogh has joined #bitcoin-core-dev
726 2016-09-21T22:09:04  *** justanotheruser has joined #bitcoin-core-dev
727 2016-09-21T22:09:09  <murch1> sipa: It seems to me that the MIN_CHANGE of 0.01 BTC is the one thing that keeps the UTXO pool of Core wallets so small.
728 2016-09-21T22:09:26  <gmaxwell> murch1: making larger change may result in more optimial selection, without regard to privacy.  But agressively doing that in general would be very bad for privacy.
729 2016-09-21T22:09:44  <murch1> I'm not sure it would make sense to make it smaller. I recently ran a series of tests with the RandomWallet with different levels of MIN_CHANGE. ……… Searching………
730 2016-09-21T22:10:58  <gmaxwell> If it always spends all the coins paid to a paritcular address, that would not have that downside-- and would even be good for privacy, since they wouldn't get pulled into other transactions where they're cosslinked.
731 2016-09-21T22:11:16  *** xinxi has joined #bitcoin-core-dev
732 2016-09-21T22:12:33  <murch1> gmaxwell: I model almost the complete transaction process, e.g. UTXO are unique, have value and confirmation height. Adding an Address is not that much work. The issue is with modelling address reuse behavior. I'm already making generous assumptions about transaction sizes by working off of only one real-world scenario data set, I'm also guessing at intervals between transactions. Pulling Address behavior from thin air seemed another
733 2016-09-21T22:13:02  <gmaxwell> yea, well I saw you were working off real data, so I had my hopes up. :P
734 2016-09-21T22:13:16  <sipa> murch1: another idea may be to tie the minimum change to a percentage of the sent amount
735 2016-09-21T22:13:33  <murch1> gmaxwell: The dataset is only positive and negative integers. Not even the order is actually really correct.
736 2016-09-21T22:13:58  <murch1> because outgoing payments get recorded when requested and incoming only after confirmed.
737 2016-09-21T22:14:13  <murch1> I have no clue when the transactions occurred or anything about addresses. :(
738 2016-09-21T22:15:25  <gmaxwell> well, sensible wallets will not spend unconfirmed coins from third parties, so that ordering sounds basically correct.
739 2016-09-21T22:15:44  <kanzure> murch1: i think you are experiencing message cutoff. there are various ways to force your irc client to split your text into multiple messages.
740 2016-09-21T22:17:15  <luke-jr> what is the purpose of share/qt/protobuf.pri?
741 2016-09-21T22:17:54  *** xinxi has quit IRC
742 2016-09-21T22:18:16  <kanzure> gmaxwell: when i have looked at coin selection (for some reason i reimplemented the stochastic approximation approach?), my thinking was "gee it would be hard to express complex preference profiles for how i would like a good coin selection method to do my bidding for me". there are a bunch of different knobs to tweak- probably it will end up being wallet developers that pick some "sane choices" instead of exposing this to users.. dunno.
743 2016-09-21T22:18:32  <gmaxwell> other possible data sources would be taking 'wallets' extracted from the blockchain via taint analysis cross linking. E.g. pick a random transaction, add all addresses that its inputs were paid too. Then find all transactions that spend coins paid to those addresses, add all their inputs, and repeat until no more is added.
744 2016-09-21T22:18:53  <murch1> sipa: Concerning Size of the MIN_CHANGE: I've run 10 iteratios of RandomWallet with MIN_CHANGE 10 sats, 100 sats, 1000 sats,…,1BTC.  There is a tiny bit of a dip on 1mBTC, the first palpable drop in average UTXO pool size is at 0.01BTC, it really goes down on 0.1 BTC.
745 2016-09-21T22:19:31  <sipa> murch1: but that does depend on the order of magnitude of the amounts you are dealing with
746 2016-09-21T22:19:43  <murch1> true
747 2016-09-21T22:19:49  <sipa> someone who regularly receives and sends small amounts may want a smaller setting for that
748 2016-09-21T22:19:55  <murch1> I'm still working of the same MoneyPot dataset.
749 2016-09-21T22:20:06  <gmaxwell> kanzure: I am doubtful users can usefully chose on this... but there are choices on the efficient frontier. E.g. I cannot think of _any_ downside to adding all inputs paying to an address you're spending (up to some maximum). I think it's strictly superior to not doing so.
750 2016-09-21T22:20:16  <murch1> kanzure: Thanks
751 2016-09-21T22:21:57  <murch1> completely off-topic, but Pidgin sucks for IRC • I used to have a decent client when I still used Linux, but I've only started using IRC for Bitcoin again recently. Any recommendation for a decent IRC client?
752 2016-09-21T22:22:10  <murch1> on Linux?
753 2016-09-21T22:22:34  <murch1> You probably meant the message to gmaxwell before?
754 2016-09-21T22:25:11  <murch1> sipa: That's basically what "DoubleWallet" does. It sets MIN_CHANGE to the sent amount (i.e. the percentage is 100%). It has consistently a much larger UTXO pool than Core on the P2PKH sim.
755 2016-09-21T22:25:32  <sipa> murch1: irssi
756 2016-09-21T22:25:38  <murch1> gmaxwell: If the message was cut off before.
757 2016-09-21T22:25:49  <murch1> gmaxwell: I model almost the complete transaction process, e.g. UTXO are unique, have value and confirmation height. Adding an Address is not that much work. The issue is with modelling address reuse behavior.
758 2016-09-21T22:25:49  <sipa> used it exclusively for over 10 years now
759 2016-09-21T22:25:54  <murch1> gmaxwell: I'm already making generous assumptions about transaction sizes by working off of only one real-world scenario data set, I'm also guessing at intervals between transactions. Pulling Address behavior from thin air seemed another huge endeavor.
760 2016-09-21T22:26:00  <kanzure> gmaxwell: i think change creation can be informed by known long-term behavior of your wallet-- perhaps you know you're going to be making payments in a very specific way, even long-term pre-planned payments. OTOH, it's probably the folks that /don't/ have this foresight who would benefit the most from better privacy in coin selection.
761 2016-09-21T22:27:00  <kanzure> ((well also the general benefit that everyone receives from good coin selection everywhere.))
762 2016-09-21T22:31:47  *** murch_ has joined #bitcoin-core-dev
763 2016-09-21T22:33:03  *** [Author] has joined #bitcoin-core-dev
764 2016-09-21T22:34:05  <murch_> sipa: Tried that, but it took me forever to figure out how to get anywhere. I'll try again maybe, when I have a few days to just play around with it. Got something else now, I think.
765 2016-09-21T22:34:15  <murch_> sipa: did you see that about DoubleWallet?
766 2016-09-21T22:35:21  *** murch1 has quit IRC
767 2016-09-21T22:35:28  *** murch_ is now known as murch
768 2016-09-21T22:37:00  *** sipa has quit IRC
769 2016-09-21T22:37:17  <luke-jr> ugh, we added unlicensed-or-GPL code to master (and soon 0.13..)
770 2016-09-21T22:42:07  *** sipa_ has joined #bitcoin-core-dev
771 2016-09-21T22:44:57  <GitHub177> [bitcoin] MarcoFalke opened pull request #8783: [share] remove qt/protobuf.pri (master...Mf1609-deleteqtProto) https://github.com/bitcoin/bitcoin/pull/8783
772 2016-09-21T22:48:37  *** MarcoFalke has quit IRC
773 2016-09-21T22:48:52  *** moli has joined #bitcoin-core-dev
774 2016-09-21T22:49:15  *** molz has quit IRC
775 2016-09-21T22:52:14  *** murch has quit IRC
776 2016-09-21T22:56:56  <warren> luke-jr: where?
777 2016-09-21T22:57:12  <luke-jr> warren: l_atomic.m4
778 2016-09-21T22:57:24  <luke-jr> author is okay with licensing it under MIT-like terms, so workign on that
779 2016-09-21T22:58:00  <warren> great
780 2016-09-21T23:02:04  *** xinxi has joined #bitcoin-core-dev
781 2016-09-21T23:06:45  *** LeMiner has quit IRC
782 2016-09-21T23:07:07  *** xinxi has quit IRC
783 2016-09-21T23:07:54  *** LeMiner has joined #bitcoin-core-dev
784 2016-09-21T23:11:37  *** jnewbery has quit IRC
785 2016-09-21T23:12:25  <GitHub136> [bitcoin] luke-jr opened pull request #8784: Copyright headers for build scripts (master...license_build) https://github.com/bitcoin/bitcoin/pull/8784
786 2016-09-21T23:16:44  *** rogerwilco has quit IRC
787 2016-09-21T23:17:14  *** rogerwilco has joined #bitcoin-core-dev
788 2016-09-21T23:25:46  *** LeMiner2 has joined #bitcoin-core-dev
789 2016-09-21T23:27:16  *** jnewbery has joined #bitcoin-core-dev
790 2016-09-21T23:28:20  *** LeMiner has quit IRC
791 2016-09-21T23:28:20  *** LeMiner2 is now known as LeMiner
792 2016-09-21T23:29:18  *** To7 has quit IRC
793 2016-09-21T23:41:21  *** veleiro has quit IRC
794 2016-09-21T23:51:46  *** xinxi has joined #bitcoin-core-dev