1 2016-09-21 01:59:36	0|phantomcircuit|is there some reason im not aware of that the wallet functions aren't acquiring the lock themselves?
  2 2016-09-21 01:59:46	0|phantomcircuit|instead of relying on the caller to have acquired the lock?
  3 2016-09-21 02:39:24	0|phantomcircuit|luke-jr: ^
  4 2016-09-21 02:40:01	0|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)
  5 2016-09-21 02:41:35	0|luke-jr|phantomcircuit: my guess would be so they could be used recursively
  6 2016-09-21 03:02:35	0|Atomic_zEU0b|hey
  7 2016-09-21 03:19:38	0|phantomcircuit|gmaxwell: the LOCK construct is recursive right?
  8 2016-09-21 03:33:06	0|luke-jr|pretty sure it isn't. or at least can't be relied on to be.
  9 2016-09-21 05:38:20	0|wumpus|phantomcircuit: yes, the default mutex used in bitcoin core is a recursive one
 10 2016-09-21 05:39:06	0|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)
 11 2016-09-21 05:39:36	0|wumpus|note that new code in general tries to use normal, single-use mutexes
 12 2016-09-21 06:08:48	0|luke-jr|wumpus: pretty sure I hit a deadlock from locking the same mutex twice in a thread, fwiw
 13 2016-09-21 06:09:25	0|wumpus|that is very possible, but not with the main, wallet locks and such as they are recursive mutexes
 14 2016-09-21 06:10:19	0|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
 15 2016-09-21 06:11:26	0|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?
 16 2016-09-21 06:11:56	0|wumpus|let's close it in favor of #8765
 17 2016-09-21 06:12:29	0|luke-jr|oh, missed that
 18 2016-09-21 06:12:37	0|wumpus|he had missed your pull too
 19 2016-09-21 06:12:45	0|GitHub113|[13bitcoin] 15laanwj closed pull request #8687: Bugfix: RPC/Wallet: removeprunedfunds should flush the wallet db (06master...06bugfix_removeprunedfunds) 02https://github.com/bitcoin/bitcoin/pull/8687
 20 2016-09-21 06:16:02	0|GitHub23|13bitcoin/06master 14c6f5ca8 15Jonas Schnelli: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds
 21 2016-09-21 06:16:02	0|GitHub23|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1c24d5f63720...b4f53641a95d
 22 2016-09-21 06:16:03	0|GitHub23|13bitcoin/06master 14b4f5364 15Wladimir J. van der Laan: Merge #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds...
 23 2016-09-21 06:16:12	0|GitHub106|[13bitcoin] 15laanwj closed pull request #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds (06master...062016/09/flush_wallet_dump) 02https://github.com/bitcoin/bitcoin/pull/8765
 24 2016-09-21 08:39:34	0|MarcoFalke|jonasschnelli: Would it be hard to use the theme for the text+background as luke-jr suggests?
 25 2016-09-21 08:39:44	0|MarcoFalke|Anyway style nits can be fixed later, 8371 looks good now
 26 2016-09-21 08:40:27	0|MarcoFalke|This is the most important gui change for 0.14. Better get it in sooner than later
 27 2016-09-21 08:40:33	0|jonasschnelli|MarcoFalke: Yes. This could be done later...
 28 2016-09-21 08:40:46	0|luke-jr|indeed
 29 2016-09-21 08:40:58	0|jonasschnelli|Also. I'm not sure if theme based colors together with the icon and the progress bar will look nice
 30 2016-09-21 08:41:13	0|jonasschnelli|I guess we also would need to ensure the singlecoloricon fits the theme...
 31 2016-09-21 08:41:22	0|jonasschnelli|also the blackish overlay is something that looks good IMO
 32 2016-09-21 08:41:40	0|jonasschnelli|gives a look that its something "important" to read..
 33 2016-09-21 08:41:57	0|luke-jr|singlecoloricon is designed specifically to fit the theme :p
 34 2016-09-21 08:42:12	0|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
 35 2016-09-21 08:42:38	0|jonasschnelli|the inverted colors as an overlay make sense from an UX perspetive IMO.
 36 2016-09-21 08:43:40	0|luke-jr|I'm not aware of a single app that inverts colours for modal dialogs.
 37 2016-09-21 08:48:17	0|jonasschnelli|Luke-Jr: how should it look then?
 38 2016-09-21 08:50:38	0|luke-jr|however modal dialogs normally look for the particular user's style
 39 2016-09-21 08:51:56	0|jonasschnelli|But it's not a modal dialog... it's an overlay.
 40 2016-09-21 08:52:11	0|luke-jr|good UX lies in behaving and looking as the user expects IMO
 41 2016-09-21 08:52:17	0|luke-jr|jonasschnelli: what's the difference?
 42 2016-09-21 08:52:34	0|jonasschnelli|Its in the same window
 43 2016-09-21 08:52:52	0|jonasschnelli|It overlays the controls.
 44 2016-09-21 08:53:13	0|jonasschnelli|Using a QDialog with modal flag would be wrong IMO
 45 2016-09-21 08:53:50	0|luke-jr|preventing interaction with the controls is precisely what model dialogs are meant to be used for.
 46 2016-09-21 08:53:55	0|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
 47 2016-09-21 08:54:14	0|jonasschnelli|Yes. But do you think a QDialog with modal flag would look appropriate?
 48 2016-09-21 08:54:14	0|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
 49 2016-09-21 08:54:52	0|sipa|it also doesn't need preventing interaction with the entire application
 50 2016-09-21 08:55:03	0|sipa|opening the debug window presumably should work fine
 51 2016-09-21 08:55:05	0|luke-jr|sipa: good point
 52 2016-09-21 08:55:58	0|jonasschnelli|Yes. It a partial-modal overlay. :)
 53 2016-09-21 08:56:05	0|luke-jr|KMail shows an overlay while it loads a folder
 54 2016-09-21 08:56:13	0|luke-jr|so it seems the overlay stuff is standard
 55 2016-09-21 08:56:19	0|luke-jr|at least to some degree
 56 2016-09-21 08:56:38	0|jonasschnelli|I think we could try to attach it more to the theme colors once its merged
 57 2016-09-21 08:56:59	0|jonasschnelli|before we do cosmetic changes, we should address the problem that people download Core and start receiving funds that are then stuck.
 58 2016-09-21 08:57:02	0|luke-jr|yes, I agree, this doesn't need to hold back merging
 59 2016-09-21 08:57:04	0|sipa|use the text color as background and background color as text? :)
 60 2016-09-21 08:57:11	0|sipa|yes agree, not a blocker
 61 2016-09-21 08:57:13	0|jonasschnelli|Yes. Something like that
 62 2016-09-21 08:57:15	0|wumpus|+1 on getting it merged
 63 2016-09-21 08:57:25	0|sipa|ha, blocker... for a modal overlay
 64 2016-09-21 08:57:31	0|jonasschnelli|heh!
 65 2016-09-21 08:57:40	0|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
 66 2016-09-21 08:57:41	0|wumpus|hah
 67 2016-09-21 08:58:12	0|wumpus|even an ugly black 'censored' box would be better than what there is now :p
 68 2016-09-21 08:58:21	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8371 needs another ACK (or a re-ack from MarcoFalke) before I merge it.
 69 2016-09-21 08:58:21	0|luke-jr|lol
 70 2016-09-21 08:58:30	0|MarcoFalke|ACK
 71 2016-09-21 08:58:38	0|sipa|jonasschnelli: is the header count still wrong due to that signal reporting the best candidate rather than the best header?
 72 2016-09-21 08:58:44	0|MarcoFalke|The github review sucks
 73 2016-09-21 08:58:54	0|jonasschnelli|sipa: Should be right now... because...
 74 2016-09-21 08:59:17	0|sipa|we should discuss how to integrate the ack/nack/... things with github review
 75 2016-09-21 08:59:30	0|sipa|what if you approve with a nack? :)
 76 2016-09-21 08:59:33	0|jonasschnelli|clientModel->getHeaderTipTime()
 77 2016-09-21 08:59:33	0|MarcoFalke|Don't use github review
 78 2016-09-21 08:59:39	0|luke-jr|is BlueMatt annoyed at it still? :P
 79 2016-09-21 09:00:01	0|jonasschnelli|sipa: https://github.com/bitcoin/bitcoin/pull/8371/files#diff-0db7dd184df07a48c307ccc182021a68R722
 80 2016-09-21 09:00:21	0|sipa|MarcoFalke: why not?
 81 2016-09-21 09:00:25	0|jonasschnelli|I take the time and height directly from pindexBestHeader
 82 2016-09-21 09:00:34	0|wumpus|why does github review suck? Ithink combining multple comments into one review is pretty useful
 83 2016-09-21 09:00:36	0|jonasschnelli|(each time the singal fires)
 84 2016-09-21 09:00:40	0|MarcoFalke|It shows the changes as approved by me, even though new commits were pushed
 85 2016-09-21 09:00:45	0|sipa|wumpus: agree
 86 2016-09-21 09:01:02	0|sipa|MarcoFalke: it does tell you what changes the review was for, no?
 87 2016-09-21 09:01:08	0|MarcoFalke|wumpus: But it does not hide the comments when they are solved
 88 2016-09-21 09:01:13	0|jonasschnelli|MarcoFalke: but the "timeline" implies that you have reviewd on older state?
 89 2016-09-21 09:01:15	0|jonasschnelli|thats indeed bad
 90 2016-09-21 09:01:25	0|jonasschnelli|Do they go away if a commit gets added?
 91 2016-09-21 09:01:48	0|MarcoFalke|Yes "timeline". But it is possible to push commits such that they appear in the past
 92 2016-09-21 09:01:50	0|jonasschnelli|I really dislike the non-removing comments on the source-code...
 93 2016-09-21 09:01:56	0|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
 94 2016-09-21 09:02:06	0|jonasschnelli|They stay also after a force push or commit that removes that code part
 95 2016-09-21 09:02:12	0|wumpus|and you can still mention the commit in review comments if you want
 96 2016-09-21 09:02:48	0|wumpus|jonasschnelli: that's slightly annoying, yes, otoh it makes the review history clearer
 97 2016-09-21 09:03:04	0|wumpus|so people don't, say, suggest the opposite thing when something has been discussed already
 98 2016-09-21 09:03:09	0|wumpus|hiding can be pretty annoying in that regard
 99 2016-09-21 09:03:18	0|jonasschnelli|Yes. That indeed true..
100 2016-09-21 09:03:18	0|sipa|i hate it when review commemts automatically disappear
101 2016-09-21 09:03:33	0|sipa|i want to judge whether a comment still applies
102 2016-09-21 09:03:37	0|wumpus|yes
103 2016-09-21 09:03:43	0|jonasschnelli|I just fear very large pages with endless amount of comments/reviews
104 2016-09-21 09:03:51	0|wumpus|indeed, github's judgement is not very good there
105 2016-09-21 09:03:55	0|sipa|you can explicitly mark as resolved, no?
106 2016-09-21 09:03:56	0|jonasschnelli|But right... it makes stuff more obvious for new reviewers
107 2016-09-21 09:04:03	0|jonasschnelli|I guess no
108 2016-09-21 09:04:07	0|luke-jr|sipa: that'd be nice, but I've never seen it
109 2016-09-21 09:04:11	0|wumpus|it just looks if the line changes and then considered the comment invalid
110 2016-09-21 09:04:35	0|jonasschnelli|wumpus: I think for review-comments, they stay even if the lines gets removed afterwards
111 2016-09-21 09:04:42	0|sipa|and it used to differ based on whether it was a commit comment or pr comment
112 2016-09-21 09:04:55	0|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.
113 2016-09-21 09:05:13	0|luke-jr|MarcoFalke: and then GitHub will change the behaviour under you :P
114 2016-09-21 09:05:19	0|sipa|MarcoFalke: just a rebase can make comments disappear
115 2016-09-21 09:06:15	0|MarcoFalke|Well, I use comments to indicate merge conflicts sometimes. I expect them to disappear after
116 2016-09-21 09:07:44	0|wumpus|MarcoFalke: you can still add 'single comments'
117 2016-09-21 09:08:11	0|wumpus|I'd expect them to still be treated the same as before on changes, unsure though
118 2016-09-21 09:09:56	0|wumpus|'disappear' is not the right word, I think they never fully disappear, just get collapsed?
119 2016-09-21 09:10:22	0|wumpus|'this comment is on a previous version of ...'
120 2016-09-21 09:11:25	0|MarcoFalke|Jup, single comments are the old fashioned comments
121 2016-09-21 09:11:44	0|MarcoFalke|wumpus: Should I add the DEFAULT_DISABLEWALLET=false in this pull?
122 2016-09-21 09:12:07	0|wumpus|MarcoFalke: would be nice to do that in one go, yes
123 2016-09-21 09:12:27	0|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.
124 2016-09-21 09:12:53	0|jonasschnelli|not sure how easy it is to get this merged in a whole
125 2016-09-21 09:13:13	0|luke-jr|perhaps I should split the refactors from multiwallet?
126 2016-09-21 09:13:15	0|jonasschnelli|Luke-Jr: The Qt wallet switch dropdown is also present when you only have a single wallet, right?
127 2016-09-21 09:13:15	0|wumpus|pretty difficult, better to do the refactoring needed step by step
128 2016-09-21 09:13:26	0|MarcoFalke|Agree
129 2016-09-21 09:13:28	0|jonasschnelli|wumpus: Yes. I though so...
130 2016-09-21 09:13:29	0|luke-jr|jonasschnelli: no, it's hidden with a single wallet
131 2016-09-21 09:13:42	0|luke-jr|wumpus: it is step by step, in commits :p
132 2016-09-21 09:13:53	0|MarcoFalke|jonasschnelli's pr is already "minimal". Though several hundred lines
133 2016-09-21 09:14:03	0|wumpus|if you want to know why, look what killed the first multi-wallet pull years ago, too much changed at once
134 2016-09-21 09:14:06	0|jonasschnelli|Mostly search and replace thought: https://github.com/bitcoin/bitcoin/pull/8764
135 2016-09-21 09:14:08	0|wumpus|yes jonasschnelli's PR is minimal
136 2016-09-21 09:14:14	0|wumpus|luke-jr's not so much
137 2016-09-21 09:14:18	0|jonasschnelli|I think we need to go in small step PRs
138 2016-09-21 09:14:39	0|luke-jr|ok, I'll open a new PR with just some refactoring
139 2016-09-21 09:14:51	0|MarcoFalke|Also, I like the approach of defaultWallet()
140 2016-09-21 09:14:52	0|luke-jr|unless you think I should do each refactor separately.. ._.
141 2016-09-21 09:14:54	0|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
142 2016-09-21 09:15:17	0|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
143 2016-09-21 09:16:06	0|wumpus|lol I had an adverse reaction on seeing the word 'boost' even though it's used in a completely different context
144 2016-09-21 09:16:11	0|luke-jr|XD
145 2016-09-21 09:16:13	0|jonasschnelli|hehe
146 2016-09-21 09:17:13	0|jonasschnelli|Luke-Jr: What do you think about exposing the addWallet stuff to RPC?
147 2016-09-21 09:17:24	0|jonasschnelli|the -wallet= approach of adding wallets is kinda limited on runtime
148 2016-09-21 09:17:32	0|luke-jr|jonasschnelli: intentionally so
149 2016-09-21 09:17:38	0|wumpus|jonasschnelli: can be sone later
150 2016-09-21 09:17:44	0|luke-jr|for the "too much in one PR" reason
151 2016-09-21 09:17:50	0|jonasschnelli|Yes. Thats true
152 2016-09-21 09:17:58	0|wumpus|runtime wallet loading and unloading is super-spiffy,but harder to get right
153 2016-09-21 09:18:00	0|luke-jr|changing wallets at runtime makes this a lot more complex
154 2016-09-21 09:18:04	0|wumpus|yes,that
155 2016-09-21 09:18:13	0|jonasschnelli|Okay. I see. Agree on that.
156 2016-09-21 09:18:46	0|luke-jr|(especially closing)
157 2016-09-21 09:18:48	0|wumpus|same as with the wallet HD support, it's better to do small (but significant) steps at a time
158 2016-09-21 09:18:55	0|jonasschnelli|Luke-Jr: In my tests, the Qt drop-down stays there even with a single wallet
159 2016-09-21 09:19:46	0|luke-jr|jonasschnelli: hmm, that's a bug then
160 2016-09-21 09:19:56	0|luke-jr|IMO
161 2016-09-21 09:20:15	0|luke-jr|(at least in the current stage, I don't think normal users should be exposed to the feature)
162 2016-09-21 09:20:39	0|luke-jr|oh, the *debug* dropdown should stay with only one wallet though
163 2016-09-21 09:20:43	0|luke-jr|because it has a (none) option
164 2016-09-21 09:21:28	0|jonasschnelli|Okay. I'll test some more...
165 2016-09-21 09:21:34	0|luke-jr|actually tempting to make that the default, so users have yet one more step to compromise their wallet..
166 2016-09-21 09:22:13	0|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
167 2016-09-21 09:22:38	0|MarcoFalke|jup
168 2016-09-21 09:22:40	0|luke-jr|wumpus: never tried, but I speculate you'd do something like the origin-pull remote trick
169 2016-09-21 09:22:40	0|MarcoFalke|I tried it
170 2016-09-21 09:22:44	0|wumpus|"Add more commits by pushing to the patch-4 branch on unsystemizer/bitcoin." ah
171 2016-09-21 09:22:48	0|wumpus|let's just try that
172 2016-09-21 09:22:56	0|MarcoFalke|git add remote unsys ...
173 2016-09-21 09:23:03	0|luke-jr|oh, it actually gives you access to his personal repo? :o
174 2016-09-21 09:23:03	0|MarcoFalke|git push unsys patch-4 -f
175 2016-09-21 09:23:14	0|MarcoFalke|luke-jr: Only this branch, IIRC
176 2016-09-21 09:23:30	0|wumpus|MarcoFalke: yes I was thining to difficult, I thought I had to push to some special pulls branch on bitcoin/bitcoin
177 2016-09-21 09:23:31	0|luke-jr|what happens if I open a PR for one of MarcoFalke's branches? <.<
178 2016-09-21 09:24:02	0|MarcoFalke|Hmm, good question
179 2016-09-21 09:24:18	0|luke-jr|MarcoFalke: got something to PR I can try it with?  :D
180 2016-09-21 09:24:32	0|MarcoFalke|One sec
181 2016-09-21 09:25:04	0|luke-jr|dad932c needs to be fixed, if you want something trivial
182 2016-09-21 09:26:52	0|wumpus|"git push -f git@github.com:unsystemizer/bitcoin.git HEAD:patch-4" seems to have worked
183 2016-09-21 09:30:47	0|wumpus|feels a bit like intruding to push to someone elses repository, but okay, it's very practical in this case
184 2016-09-21 09:31:01	0|MarcoFalke|luke-jr: https://github.com/bitcoin/bitcoin/compare/master...MarcoFalke:Mf1609-ContributeDoc?expand=1
185 2016-09-21 09:31:58	0|GitHub92|[13bitcoin] 15luke-jr opened pull request #8771: CONTRIBUTING: Mention not to open several pulls (06master...06Mf1609-ContributeDoc) 02https://github.com/bitcoin/bitcoin/pull/8771
186 2016-09-21 09:32:07	0|luke-jr|no checkbox in this case
187 2016-09-21 09:32:50	0|GitHub93|13bitcoin/06master 1404d91f4 15unsystemizer: Trivial: Fix ISO URL, capitalization...
188 2016-09-21 09:32:50	0|GitHub93|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b4f53641a95d...84c9a048559d
189 2016-09-21 09:32:51	0|GitHub93|13bitcoin/06master 1484c9a04 15Wladimir J. van der Laan: Merge #8769: Trivial: Fix ISO URL, capitalization...
190 2016-09-21 09:32:52	0|luke-jr|hm, review won't let me set a review-type for the PR either. :P
191 2016-09-21 09:33:00	0|GitHub138|[13bitcoin] 15laanwj closed pull request #8769: Trivial: Fix ISO URL, capitalization (06master...06patch-4) 02https://github.com/bitcoin/bitcoin/pull/8769
192 2016-09-21 09:36:34	0|MarcoFalke|wumpus, can you do "git push -f git@github.com:MarcoFalke/bitcoin.git HEAD:Mf1609-ContributeDoc"?
193 2016-09-21 09:36:58	0|wumpus|sure, does it matter what I overwrite it with?
194 2016-09-21 09:37:06	0|luke-jr|it should fail anyway
195 2016-09-21 09:37:08	0|MarcoFalke|no
196 2016-09-21 09:37:18	0|MarcoFalke|does not matter
197 2016-09-21 09:37:19	0|wumpus|! [remote rejected] HEAD -> Mf1609-ContributeDoc (permission denied)
198 2016-09-21 09:37:52	0|luke-jr|good, GitHub isn't totally incompetent. ☺
199 2016-09-21 09:38:43	0|wumpus|the access control code just became extremely complex though, wouldn't be surprised if someone still discovered a loophole
200 2016-09-21 09:39:41	0|wumpus|on some level this feature creeps me out
201 2016-09-21 09:39:50	0|MarcoFalke|Open a pull request to bitcoin:master in some other repo. Force push to bitcoin:master...
202 2016-09-21 09:39:52	0|sipa|likewise
203 2016-09-21 09:39:59	0|wumpus|git is meant to be authority-less
204 2016-09-21 09:40:06	0|luke-jr|it'd make slightly more sense if it had you push to the project's repo (the PR refs), but oh well
205 2016-09-21 09:40:54	0|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
206 2016-09-21 09:41:01	0|luke-jr|tempting to try opening a PR against both Core and Classic, and see if one can influence the other..
207 2016-09-21 09:41:34	0|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
208 2016-09-21 09:42:37	0|wumpus|luke-jr: hah
209 2016-09-21 09:43:08	0|wumpus|that's a clever idea, but let's not do it in this case, we don't want more allegations of attacking classic
210 2016-09-21 09:44:36	0|GitHub10|[13bitcoin] 15luke-jr opened pull request #8772: [0.13] Backports (060.13...06backports-0.13) 02https://github.com/bitcoin/bitcoin/pull/8772
211 2016-09-21 09:48:52	0|GitHub137|[13bitcoin] 15luke-jr opened pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (06master...06bugfix_link_20160921) 02https://github.com/bitcoin/bitcoin/pull/8773
212 2016-09-21 09:51:15	0|MarcoFalke|wumpus: Can I get permission to merge doc changes (comments, markdown, ...)?
213 2016-09-21 09:53:42	0|MarcoFalke|Otherwise I will just ping you when I feel soemthing trivial can be merged
214 2016-09-21 09:53:49	0|GitHub124|[13bitcoin] 15luke-jr opened pull request #8774: Qt refactors to better abstract wallet access (06master...06multiwallet_prefactor_qt) 02https://github.com/bitcoin/bitcoin/pull/8774
215 2016-09-21 09:57:08	0|GitHub30|[13bitcoin] 15luke-jr opened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (06master...06multiwallet_prefactor_rpc) 02https://github.com/bitcoin/bitcoin/pull/8775
216 2016-09-21 10:01:19	0|GitHub181|[13bitcoin] 15luke-jr opened pull request #8776: Wallet refactoring leading up to multiwallet (06master...06multiwallet_prefactor_wallet) 02https://github.com/bitcoin/bitcoin/pull/8776
217 2016-09-21 10:01:52	0|luke-jr|there we go, I think that's as far as I can go with split PRs until they get merged :p
218 2016-09-21 10:25:04	0|wumpus|MarcoFalke: sure
219 2016-09-21 10:28:14	0|GitHub94|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/84c9a048559d...886e8c9b7269
220 2016-09-21 10:28:15	0|GitHub94|13bitcoin/06master 14fab9107 15MarcoFalke: init: Get rid of fDisableWallet
221 2016-09-21 10:28:16	0|GitHub94|13bitcoin/06master 14886e8c9 15Wladimir J. van der Laan: Merge #8768: init: Get rid of fDisableWallet...
222 2016-09-21 10:28:16	0|GitHub94|13bitcoin/06master 14fa58edb 15MarcoFalke: [wallet] Introduce DEFAULT_DISABLE_WALLET
223 2016-09-21 10:28:29	0|GitHub81|[13bitcoin] 15laanwj closed pull request #8768: init: Get rid of fDisableWallet (06master...06Mf1609-initDisableWallet) 02https://github.com/bitcoin/bitcoin/pull/8768
224 2016-09-21 10:29:57	0|wumpus|MarcoFalke: certainly trivial things like https://github.com/bitcoin/bitcoin/pull/8773 you can just merge if they check out
225 2016-09-21 10:31:59	0|GitHub109|13bitcoin/06master 146f933c6 15Luke Dashjr: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
226 2016-09-21 10:31:59	0|GitHub109|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/886e8c9b7269...52b5a8785de7
227 2016-09-21 10:32:01	0|GitHub109|13bitcoin/06master 1452b5a87 15MarcoFalke: Merge #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
228 2016-09-21 10:32:09	0|GitHub143|[13bitcoin] 15MarcoFalke closed pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (06master...06bugfix_link_20160921) 02https://github.com/bitcoin/bitcoin/pull/8773
229 2016-09-21 10:33:02	0|wumpus|re: wallet, I'd really like to get https://github.com/bitcoin/bitcoin/pull/7551 in
230 2016-09-21 10:33:15	0|wumpus|I think it's even more important than multiwallet
231 2016-09-21 10:33:57	0|wumpus|well it's pretty much orthagonal but okay
232 2016-09-21 10:34:50	0|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
233 2016-09-21 10:34:57	0|sipa|wumpus: thabks for the reminder, eill review
234 2016-09-21 10:35:03	0|sipa|*will
235 2016-09-21 10:35:05	0|sipa|*thanks
236 2016-09-21 10:35:07	0|wumpus|thanks
237 2016-09-21 10:38:44	0|MarcoFalke|Sry, I think qt no longer compiles on master.
238 2016-09-21 10:39:03	0|sipa|uh-oh
239 2016-09-21 10:39:09	0|MarcoFalke|Forgot to #include wallet.h
240 2016-09-21 10:39:44	0|MarcoFalke|the "introduce DEFAULT_DISABLE_WALLET" is more involved
241 2016-09-21 10:39:47	0|MarcoFalke|in qt
242 2016-09-21 10:39:52	0|MarcoFalke|than search and replace
243 2016-09-21 10:40:17	0|MarcoFalke|might want to properly fix it, now that multiwallet is the goal
244 2016-09-21 10:47:55	0|wumpus|let's first get it to compile again
245 2016-09-21 10:50:07	0|sipa|*commits a #if 0 .. #endif around all .cpp files* - what did you do?! - it compiles again!
246 2016-09-21 10:50:27	0|wumpus|hehe
247 2016-09-21 10:51:06	0|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
248 2016-09-21 10:52:01	0|wumpus|then do it the proper way some other time
249 2016-09-21 10:52:12	0|wumpus|re-do
250 2016-09-21 10:53:56	0|MarcoFalke|wumpus: Will create a pull
251 2016-09-21 10:54:21	0|wumpus|but if it involves multiwallet changes may be better to revert the current naive commit for now?
252 2016-09-21 10:54:56	0|MarcoFalke|should work without multiwallet changes
253 2016-09-21 10:55:02	0|MarcoFalke|Is this "Method names start with upper case" a style thing?
254 2016-09-21 10:55:05	0|wumpus|e.g. just fa58edb not the other commitin that pull
255 2016-09-21 10:55:18	0|wumpus|MarcoFalke: dunno, seems another satoshi-ism
256 2016-09-21 10:55:35	0|MarcoFalke|I think we have half of the names start upper case and the other half don't
257 2016-09-21 10:55:43	0|wumpus|qt code uses lowerCamelCase at least
258 2016-09-21 10:55:44	0|MarcoFalke|Never sure what to use in fresh code
259 2016-09-21 10:55:55	0|MarcoFalke|ok
260 2016-09-21 10:56:26	0|wumpus|nah if you sak me for something new and independent I'd suggest using lowerCamelCase, that's a more common C++ naming convention
261 2016-09-21 10:56:37	0|wumpus|if you change existing code just go with the style of that code
262 2016-09-21 10:56:57	0|sipa|hmm, nearly all of the existing core code uses capitalized class and function names
263 2016-09-21 10:57:07	0|sipa|so i'd rather not introduce something else
264 2016-09-21 10:57:36	0|sipa|the developer notes used to mention this
265 2016-09-21 10:57:41	0|wumpus|I really have no strong opinion on it
266 2016-09-21 10:57:56	0|wumpus|I'm fine with either, but don't mix them in one class/unit
267 2016-09-21 10:58:39	0|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
268 2016-09-21 11:01:38	0|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()
269 2016-09-21 11:03:03	0|wumpus|capitalizing class names, on the other hand, makes sense to keep them apart
270 2016-09-21 11:04:11	0|sipa|all stl functions are lower_separated_by_underscore()
271 2016-09-21 11:04:30	0|wumpus|yes, that's a valid choice too
272 2016-09-21 11:04:37	0|wumpus|snake_case :)
273 2016-09-21 11:04:58	0|sipa|i perdonally find lowerCaseFollowedByUpper very strange, but it's all highly subjective
274 2016-09-21 11:05:04	0|wumpus|many projects use that for variables and member variables, that's reasonable sane
275 2016-09-21 11:07:22	0|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
276 2016-09-21 11:08:02	0|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
277 2016-09-21 11:09:08	0|wumpus|having a separate naming convention for classes also avoids creating a class with the same name as a function
278 2016-09-21 11:10:43	0|wumpus|in any case I have no problems with stl-style either, except that it reminds me of boost :-)
279 2016-09-21 11:11:48	0|GitHub122|[13bitcoin] 15MarcoFalke opened pull request #8777: [qt] WalletModel: Expose disablewallet (06master...06Mf1609-initDisableWallet) 02https://github.com/bitcoin/bitcoin/pull/8777
280 2016-09-21 11:13:12	0|sipa|wumpus: i guess i'm biased because i learned c++ from bitcoin's codebase :)
281 2016-09-21 11:13:35	0|sipa|well, i knew c++ from university, but that was purely theory without ajy software development experience
282 2016-09-21 11:14:42	0|wumpus|yes, that can twist your mind :)
283 2016-09-21 11:15:35	0|wumpus|MarcoFalke: I'm confused by #8777, why do we have a wallet model if the wallet is disabled
284 2016-09-21 11:15:50	0|wumpus|did I really make it that way?
285 2016-09-21 11:16:13	0|MarcoFalke|My method is static
286 2016-09-21 11:17:21	0|wumpus|oh, okay, yes, that can work
287 2016-09-21 11:17:51	0|MarcoFalke|I think there is no walletModel in case of -disablewallet=1
288 2016-09-21 11:18:01	0|wumpus|static methods cover no instances, so can apply to all instances
289 2016-09-21 11:18:06	0|wumpus|yes
290 2016-09-21 11:18:08	0|wumpus|phew
291 2016-09-21 11:19:34	0|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.
292 2016-09-21 11:19:58	0|sipa|wumpus: i did know C pretty well beforehand, maybe that helped :)
293 2016-09-21 11:21:10	0|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, ...
294 2016-09-21 11:22:17	0|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.
295 2016-09-21 11:22:18	0|MarcoFalke|So let's fetch some tea until travis clears the backlog
296 2016-09-21 11:23:34	0|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 :)
297 2016-09-21 11:27:47	0|wumpus|sipa: hah!
298 2016-09-21 11:28:30	0|wumpus|MarcoFalke: we could cancel all the preceeding builds as they're going to fail anyway
299 2016-09-21 11:30:30	0|MarcoFalke|done. Should pick up the pull now
300 2016-09-21 11:31:33	0|MarcoFalke|reminds me that no entry in the travis matrix has qt builds enabled
301 2016-09-21 11:31:57	0|MarcoFalke|IIRC osx cross build does it (silently)
302 2016-09-21 11:32:03	0|wumpus|that was disabled for *somereason cfields probably knows*
303 2016-09-21 11:32:14	0|MarcoFalke|timeouts?
304 2016-09-21 11:32:30	0|wumpus|possibly timeout-related back when there were problems with caching after the travis trusty switch
305 2016-09-21 11:32:41	0|wumpus|yes
306 2016-09-21 11:34:14	0|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
307 2016-09-21 11:34:56	0|wumpus|yea docker solves a problem we don't have, here
308 2016-09-21 11:35:15	0|MarcoFalke|Was on an unrelated note  ;)
309 2016-09-21 11:36:00	0|MarcoFalke|(travis has no plans to switch to xenial soon)
310 2016-09-21 11:36:06	0|wumpus|testing native osx/win would be interesting, but I guess that runs into license issues
311 2016-09-21 11:36:26	0|MarcoFalke|Oh, travis has native osx?
312 2016-09-21 11:36:49	0|wumpus|and in the case of windows multi-stage issues: we want to build on trusty, then run the tests on an actualwindows machine
313 2016-09-21 11:37:46	0|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
314 2016-09-21 11:39:08	0|MarcoFalke|(Right now we are bound to whatever ubuntu 14.04 provides us. Though, deterministic builds of the toolchain would help to untangle this)
315 2016-09-21 11:39:36	0|wumpus|switching to xenial would be a disaster right now, esp for windows build
316 2016-09-21 11:40:29	0|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 :)
317 2016-09-21 11:40:31	0|MarcoFalke|No one detected this. We should have run tests on xenial at least for the release
318 2016-09-21 11:40:50	0|MarcoFalke|But then it is unfeasible to try every os and combination of toolchains
319 2016-09-21 11:41:06	0|wumpus|well this is a cross build issue that didn't get detected
320 2016-09-21 11:41:11	0|wumpus|we can't test every toolchain in existence
321 2016-09-21 11:41:22	0|wumpus|right
322 2016-09-21 11:41:45	0|MarcoFalke|So cfields work sounds like the right step
323 2016-09-21 11:41:45	0|wumpus|unfortunately, there are plenty of mingw toolchains that create absolutely broken windows code
324 2016-09-21 11:41:57	0|wumpus|we used to have that issue, and now it's back
325 2016-09-21 11:42:57	0|MarcoFalke|Looks like travis likes my pull.
326 2016-09-21 11:43:24	0|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)
327 2016-09-21 11:43:28	0|wumpus|thanks ,going to merge it
328 2016-09-21 11:44:34	0|wumpus|cfields: ^^ re clang and windows, should we consider that?
329 2016-09-21 11:45:07	0|wumpus|would be worth an experiment at least I guess
330 2016-09-21 11:45:44	0|GitHub146|13bitcoin/06master 146666ca6 15MarcoFalke: [qt] WalletModel: Expose disablewallet
331 2016-09-21 11:45:44	0|GitHub146|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/52b5a8785de7...fec6af744014
332 2016-09-21 11:45:45	0|GitHub146|13bitcoin/06master 14fec6af7 15Wladimir J. van der Laan: Merge #8777: [qt] WalletModel: Expose disablewallet...
333 2016-09-21 11:45:58	0|GitHub97|[13bitcoin] 15laanwj closed pull request #8777: [qt] WalletModel: Expose disablewallet (06master...06Mf1609-initDisableWallet) 02https://github.com/bitcoin/bitcoin/pull/8777
334 2016-09-21 12:14:06	0|GitHub170|13bitcoin/06master 147c069a7 15Pavel Janík: Do not shadow global variable
335 2016-09-21 12:14:06	0|GitHub170|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fec6af744014...cf5ebaa921a9
336 2016-09-21 12:14:07	0|GitHub170|13bitcoin/06master 14cf5ebaa 15Wladimir J. van der Laan: Merge #8656: Trivial: Do not shadow global variable fileout...
337 2016-09-21 12:14:16	0|GitHub191|[13bitcoin] 15laanwj closed pull request #8656: Trivial: Do not shadow global variable fileout (06master...0620160902_Wshadow_fileout) 02https://github.com/bitcoin/bitcoin/pull/8656
338 2016-09-21 12:44:04	0|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?
339 2016-09-21 12:44:50	0|sipa|wumpus: you're on http://coredev.tech/nextmeeting.html ?
340 2016-09-21 12:45:04	0|wumpus|oh I have the wrong link, okay
341 2016-09-21 12:45:17	0|wumpus|yep
342 2016-09-21 12:50:20	0|GitHub78|[13bitcoin] 15MarcoFalke closed pull request #8536: [qa] Adjust poll interval for micro-optimization of run time (06master...06Mf1608-qaOptSync) 02https://github.com/bitcoin/bitcoin/pull/8536
343 2016-09-21 12:50:58	0|jonasschnelli|wumpus: Yes. Your listed... need to remove the *_tmp.html files!
344 2016-09-21 12:51:12	0|jonasschnelli|I updated the page right after you submitted your form. :)
345 2016-09-21 12:52:07	0|jonasschnelli|Ah. instagibbs just submitted the form as well...
346 2016-09-21 12:52:47	0|instagibbs|i saw it being discussed here
347 2016-09-21 12:54:35	0|jonasschnelli|*plumbing
348 2016-09-21 13:06:27	0|MarcoFalke|jonasschnelli: I think you forgot to merge the overlay pull this morning :)
349 2016-09-21 13:07:51	0|jonasschnelli|MarcoFalke: I was hoping someone did another review,.. but will merge in the next couple of hours.
350 2016-09-21 13:08:02	0|jonasschnelli|*someone will do
351 2016-09-21 13:08:43	0|BlueMatt|luke-jr: they seem to have partially fixed the email issues
352 2016-09-21 13:08:46	0|BlueMatt|github, that is
353 2016-09-21 13:09:02	0|BlueMatt|as of yesterday i was still getting duplicate emails from them, but at least they're properly threaded
354 2016-09-21 13:10:43	0|jonasschnelli|BlueMatt: while your here.. :), do you use the contrib/debian packaging dir for your bitcoin PPA?
355 2016-09-21 13:11:10	0|BlueMatt|i forked off of it a while ago, but anything something gets updated in contrib/debian i re-sync it
356 2016-09-21 13:11:30	0|BlueMatt|iirc the only real difference is package description (the new one is pretty terrible, iirc) and changelog
357 2016-09-21 13:11:45	0|BlueMatt|new as of like 3 versions ago, that is
358 2016-09-21 13:12:29	0|jonasschnelli|BlueMatt: I guess we should add zmq to the dependencies
359 2016-09-21 13:12:46	0|jonasschnelli|which probably should result compiling with zmq
360 2016-09-21 13:12:57	0|BlueMatt|oh, thats another difference - upnp is not built-in
361 2016-09-21 13:13:06	0|BlueMatt|because of the security issues a while back, and i never re-added it
362 2016-09-21 13:13:06	0|jonasschnelli|otherwise our "official" binary comes with zmq while the PPA does not
363 2016-09-21 13:13:11	0|BlueMatt|but no one has complained, so whatever
364 2016-09-21 13:13:26	0|BlueMatt|yea, could add zmq, though also security-swiss-cheese
365 2016-09-21 13:13:34	0|BlueMatt|but maybe i should....
366 2016-09-21 13:14:00	0|jonasschnelli|I would argue that if you like to use ZMQ, you should self-compile... but, yeah...
367 2016-09-21 13:14:42	0|BlueMatt|i mean ive never heard any complaints about that or upnp
368 2016-09-21 13:15:02	0|wumpus|zmq is only used for notification, and disabled by default
369 2016-09-21 13:15:10	0|BlueMatt|(not that that indicates much, people like to keep complaints to themselves, mostly)
370 2016-09-21 13:15:28	0|BlueMatt|wumpus: I'm aware, but so is upnp in bitcoind, and its still gross :p
371 2016-09-21 13:16:02	0|BlueMatt|though i did actually get like 2/3 emails about the 12.04 empty-package update, which i found impressive
372 2016-09-21 13:16:09	0|wumpus|yes, it's up to you as maintainer, please do explain that in the issue
373 2016-09-21 13:16:47	0|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
374 2016-09-21 13:16:49	0|wumpus|people really shouldn't complain to us about the PPAs, though i guess the ppa doesn't have its own issue tracker
375 2016-09-21 13:16:56	0|wumpus|yes there's an issue, let em see
376 2016-09-21 13:17:13	0|jonasschnelli|we have contrib/debian though
377 2016-09-21 13:17:13	0|sipa|BlueMatt: a few people in #bitcoin were confused by bitcoind disappearing
378 2016-09-21 13:17:35	0|BlueMatt|oh, well if someone complained I can add it
379 2016-09-21 13:17:46	0|BlueMatt|sipa: yea, if i get emails then #bitcoin is generally guaranteed to complain
380 2016-09-21 13:17:49	0|BlueMatt|not much i could do, though :/
381 2016-09-21 13:17:58	0|sipa|BlueMatt: maybe a #!/bin/sh echo "The Bitcoin Core PPA no longer supports Ubuntu 12.04" would be better than just empty package?
382 2016-09-21 13:18:30	0|wumpus|BlueMatt: https://github.com/bitcoin/bitcoin/issues/8759
383 2016-09-21 13:18:33	0|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
384 2016-09-21 13:18:55	0|wumpus|BlueMatt: yes, I've seen that only once, the GUI tools do show it
385 2016-09-21 13:19:21	0|wumpus|it's meant for really critical notifications regarding a package, I guess this qualifies
386 2016-09-21 13:19:37	0|BlueMatt|indeed
387 2016-09-21 13:21:32	0|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
388 2016-09-21 13:22:21	0|wumpus|I started receiving so many github mails that that's the only ones I read at at the moment
389 2016-09-21 13:23:23	0|wumpus|(of course I tend to read the rest, but on github.com, not in my mailbox)
390 2016-09-21 13:25:17	0|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
391 2016-09-21 13:26:21	0|wumpus|jonasschnelli: at least the manpages will be gone from there now
392 2016-09-21 13:28:37	0|BlueMatt|wumpus: yep, still eating breakfast, give me a few :p
393 2016-09-21 13:29:04	0|wumpus|BlueMatt: yes I don't mean to hurry :p
394 2016-09-21 13:32:58	0|wumpus|re: the new github review system, is it possible to un-approve a pull?
395 2016-09-21 14:23:05	0|xinxi|Hi guys, are any documents on how to add a new type of address?
396 2016-09-21 14:24:29	0|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?
397 2016-09-21 14:42:44	0|instagibbs|murch: I'd be interested to see what effect, if any, witness discounting would have on effective paid fees per algorithm
398 2016-09-21 14:44:11	0|murch|instagibbs: Lemme have a look at the results
399 2016-09-21 14:54:08	0|murch|instagibbs: Fees are almost exactly halved through the bench.
400 2016-09-21 14:54:26	0|murch|https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
401 2016-09-21 14:55:03	0|murch|instagibbs: I've uploaded the whole output table here ^
402 2016-09-21 14:55:41	0|sipa|murch: do any of the algorithms behave significantly better/worse (in terms of average number of transaction inputs) with and without segwit?
403 2016-09-21 14:55:55	0|sipa|or number of utxos held
404 2016-09-21 14:59:56	0|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.
405 2016-09-21 15:01:39	0|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.
406 2016-09-21 15:03:57	0|instagibbs|murch: are total fees in satoshis or?
407 2016-09-21 15:04:05	0|murch|instagibbs: Yes.
408 2016-09-21 15:05:00	0|murch|instagibbs: All bitcoin values are in satoshi.
409 2016-09-21 15:19:38	0|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
410 2016-09-21 15:19:58	0|skyraider|https://www.irccloud.com/pastebin/rENd1qLg/tor%20disconnect%20callback%20incorrectly%20firing%20on%200.13.0
411 2016-09-21 15:20:13	0|d4de|I was surprised today by a bunch of tor client messages in our systems. Why not SOCKS5?
412 2016-09-21 15:20:39	0|sipa|skyraider: it's just trying to reach the tor control port to open a socket
413 2016-09-21 15:20:49	0|skyraider|(for additional context, this pull request supposedly fixes that message, but apparently not https://github.com/bitcoin/bitcoin/pull/7637)
414 2016-09-21 15:20:52	0|sipa|it's enabled by default, but doesn't do anything if you don't have tor running
415 2016-09-21 15:21:03	0|skyraider|sipa: ah, so it's harmless?
416 2016-09-21 15:21:17	0|sipa|yes
417 2016-09-21 15:21:21	0|skyraider|thanks
418 2016-09-21 15:21:32	0|sipa|that PR just prevents it from spamming your debug.log all the time
419 2016-09-21 15:21:36	0|sipa|now it just mentions it onc
420 2016-09-21 15:21:38	0|sipa|*once
421 2016-09-21 15:22:47	0|sipa|you can disable it by setting listenonion=0 in bitcoin.conf
422 2016-09-21 15:22:54	0|sipa|or running with -nolistenonion
423 2016-09-21 15:25:42	0|skyraider|hmm, i received several warnings... 6, it seems
424 2016-09-21 15:28:33	0|sipa|that's unexpected
425 2016-09-21 15:28:48	0|skyraider|listenonion=0 is effective, though. no warning after applying that config setting.
426 2016-09-21 16:08:58	0|gmaxwell|murch: is your 'corewallet' with or without the extra input removal?
427 2016-09-21 16:09:16	0|murch|gmaxwell: Without pruning
428 2016-09-21 16:09:24	0|murch|i.e. extra input removal
429 2016-09-21 16:09:39	0|gmaxwell|okay
430 2016-09-21 16:11:51	0|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.
431 2016-09-21 16:13:36	0|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)
432 2016-09-21 16:14:07	0|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?)
433 2016-09-21 16:16:23	0|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?
434 2016-09-21 16:16:44	0|murch|BlueMatt: Yes, it's the coin selector from BitcoinJ.
435 2016-09-21 16:16:57	0|gmaxwell|BlueMatt: the paper says it uses "value * inputAge"
436 2016-09-21 16:17:10	0|BlueMatt|gmaxwell: it was written when using priority as selection wasnt insane :p
437 2016-09-21 16:17:23	0|BlueMatt|murch: is your "fee spent" thing just tx size * fee something, or does it actually analyze the code's fee selection behavior?
438 2016-09-21 16:18:12	0|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?
439 2016-09-21 16:18:18	0|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.
440 2016-09-21 16:18:36	0|murch|BlueMatt: It uses a flat fee of 10 satoshi per byte.
441 2016-09-21 16:18:53	0|BlueMatt|murch: ok, cool, yea, so it generates the smallest total tx bytes
442 2016-09-21 16:20:03	0|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.
443 2016-09-21 16:20:31	0|murch|BlueMatt: Unfortunately, my scenario data does not contain actual time information.
444 2016-09-21 16:21:14	0|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
445 2016-09-21 16:21:52	0|murch|BlueMatt: I have not checked just selecting "smallest bigger" yet. I just replicated what I found in the code.
446 2016-09-21 16:23:07	0|gmaxwell|BlueMatt: you mean making the final utxo set 126 times larger than bitcoin core isn't good?
447 2016-09-21 16:23:45	0|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
448 2016-09-21 16:23:45	0|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.
449 2016-09-21 16:24:20	0|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
450 2016-09-21 16:25:03	0|BlueMatt|boolean needAtLeastReferenceFee, List<TransactionOutput> candidates) throws InsufficientMoneyException {
451 2016-09-21 16:25:03	0|BlueMatt|murch: did you emulate public FeeCalculation calculateFee(SendRequest req, Coin value, List<TransactionInput> originalInputs,
452 2016-09-21 16:25:04	0|BlueMatt|?
453 2016-09-21 16:25:26	0|BlueMatt|I mean because that is, essentially, the actual coin selection algorithm, not just CoinSelector
454 2016-09-21 16:26:42	0|murch|BlueMatt: Having a look, sorry it's been a few weeks
455 2016-09-21 16:26:48	0|BlueMatt|yea, np
456 2016-09-21 16:27:34	0|BlueMatt|god this code is soooo old
457 2016-09-21 16:27:43	0|BlueMatt|wow, does no one maintain bitcoinj at all? how was this not replaced
458 2016-09-21 16:30:02	0|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
459 2016-09-21 16:30:19	0|gmaxwell|murch: so is your codebase in a position to try more hypothetical algorithims?
460 2016-09-21 16:31:32	0|murch|BlueMatt: I had missed "calculateFee", I had only discovered the CoinSelector.
461 2016-09-21 16:32:14	0|BlueMatt|murch: oh shit, that will probably significantly effect your simulation
462 2016-09-21 16:32:34	0|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.
463 2016-09-21 16:33:28	0|murch|BlueMatt: I should have written to the mailing list earlier. (._.)
464 2016-09-21 16:33:53	0|BlueMatt|murch: well either way you re-confirmed what we all knew: bitcoinj is unmaintained and its use should be significantly discouraged
465 2016-09-21 16:35:05	0|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?
466 2016-09-21 16:36:11	0|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.
467 2016-09-21 16:36:42	0|murch|Seems like I'm misrepresenting BitcoinJ here then.
468 2016-09-21 16:36:58	0|murch|perhaps also the other wallets.
469 2016-09-21 16:37:52	0|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)
470 2016-09-21 16:38:02	0|BlueMatt|murch: is your simulator in java? that code is very standalone
471 2016-09-21 16:38:15	0|sipa|i don't understand why fee estimation matters
472 2016-09-21 16:38:17	0|murch|BlueMatt: Scala actually.
473 2016-09-21 16:38:38	0|BlueMatt|sipa: its not really fee estimation, its the thing that selects between coin selection options and change
474 2016-09-21 16:38:41	0|BlueMatt|ie whether to throw away change
475 2016-09-21 16:38:59	0|sipa|for a comparable simulation across clients you should assume a constant approximate feerate on the network
476 2016-09-21 16:39:01	0|BlueMatt|murch: so you can just drop that function in, mostly? I actually have no idea about scala tooling
477 2016-09-21 16:39:09	0|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.
478 2016-09-21 16:39:10	0|BlueMatt|sipa: he does that
479 2016-09-21 16:39:15	0|sipa|and use the same fees in multiple tools
480 2016-09-21 16:39:36	0|sipa|murch: ah! you mean fee estimation of the transaction you are creating
481 2016-09-21 16:39:43	0|sipa|not feerate estimation on the network
482 2016-09-21 16:40:49	0|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.)
483 2016-09-21 16:41:50	0|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?
484 2016-09-21 16:42:29	0|BlueMatt|murch: it takes the CoinSelector and will call it three times, and select between the options based on what the resulting change is
485 2016-09-21 16:43:13	0|murch|BlueMatt: o.0 I had the impression that the CoinSelector is deterministic?!
486 2016-09-21 16:45:00	0|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"
487 2016-09-21 16:46:19	0|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".
488 2016-09-21 16:47:09	0|sipa|murch: that seems desirable to me
489 2016-09-21 16:47:10	0|murch|BlueMatt: Ah, thanks. Now I get what you meant. I should probably be able to replicate that no problem.
490 2016-09-21 16:47:16	0|sipa|(the way you do it)
491 2016-09-21 16:47:38	0|sipa|otherwise there is the added variance of how wallets determine fees
492 2016-09-21 16:48:38	0|murch|sipa: Yeah, and it would have also blown the overhead for my simulation out of proportion. I'll add it to "Future Work". ;)
493 2016-09-21 16:50:45	0|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. :)
494 2016-09-21 17:02:11	0|gmaxwell|murch: 10sat/byte or per weight? (how does the segwit analysis change it?)
495 2016-09-21 17:05:04	0|gmaxwell|murch: so are you not modling the behavior where very small change out is converted into fee to avoid creating change?
496 2016-09-21 17:13:39	0|xinxi|gmaxwell: CT uses ECDH, which is not quantum resistant. Why not use a quantum resistant key exchange crypto algorithm?
497 2016-09-21 17:14:20	0|instagibbs|xinxi: maybe #bitcoin-wizards ?
498 2016-09-21 17:14:55	0|xinxi|instagibbs: what's that for?
499 2016-09-21 17:15:27	0|instagibbs|this channel is for near-term bitcoin core development, your question is about an implementation of elements sidechain and/or future quantum advances
500 2016-09-21 17:15:35	0|instagibbs|that channel is more suitable
501 2016-09-21 17:15:45	0|xinxi|instagibbs: OK.
502 2016-09-21 17:15:56	0|instagibbs|I can answer you there
503 2016-09-21 17:18:57	0|GitHub24|[13bitcoin] 15MarcoFalke opened pull request #8779: [contrib] Delete spendfrom (06master...06Mf1609-deleteAllTheThings) 02https://github.com/bitcoin/bitcoin/pull/8779
504 2016-09-21 17:28:03	0|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.
505 2016-09-21 18:52:29	0|GitHub54|[13bitcoin] 15MarcoFalke opened pull request #8780: [rpc] Deprecate getinfo (06master...06Mf1609-getinfoDeprecate) 02https://github.com/bitcoin/bitcoin/pull/8780
506 2016-09-21 19:02:05	0|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)
507 2016-09-21 19:04:38	0|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.
508 2016-09-21 19:07:05	0|gmaxwell|I suppose a sweep could instead work from the utxo set without loss.
509 2016-09-21 19:46:48	0|GitHub125|[13bitcoin] 15MarcoFalke opened pull request #8781: [contrib] delete qt_translations.py (06master...06Mf1609-deleteQtTrans) 02https://github.com/bitcoin/bitcoin/pull/8781
510 2016-09-21 19:49:01	0|MarcoFalke|I am looking for stuff but can only find outdated crap...
511 2016-09-21 21:22:09	0|BlueMatt|<instagibbs> pfrom->GetLocalServices() & NODE_WITNESS && (nCMPCTBLOCKVersion == 2)
512 2016-09-21 21:22:10	0|BlueMatt|<instagibbs> pfrom is referring to the remote node's flags, I hope
513 2016-09-21 21:22:11	0|BlueMatt|...
514 2016-09-21 21:22:20	0|BlueMatt|<BlueMatt> I think nLocalServices refers to YOUR services
515 2016-09-21 21:22:22	0|instagibbs|apparently not we learned, which confused the hell out of me
516 2016-09-21 21:22:26	0|BlueMatt|<BlueMatt> and you store it in every CNode object
517 2016-09-21 21:22:29	0|BlueMatt|is that true?
518 2016-09-21 21:22:32	0|BlueMatt|that seems...fun?
519 2016-09-21 21:22:45	0|instagibbs|nServices is the remote's services
520 2016-09-21 21:22:57	0|sipa|will check
521 2016-09-21 21:22:59	0|BlueMatt|seems like an easy optimization for cfields to fix?
522 2016-09-21 21:22:59	0|instagibbs|but both are stored on CNode
523 2016-09-21 21:24:14	0|instagibbs|well it could be a way to remember which services you promised without reconnecting?
524 2016-09-21 21:24:41	0|instagibbs|ie remembering what other node will have for nExpectedServices
525 2016-09-21 21:25:55	0|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..)
526 2016-09-21 21:26:32	0|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
527 2016-09-21 21:28:02	0|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?
528 2016-09-21 21:28:10	0|BlueMatt|(I'm not aware of any way it could change in the current code?)
529 2016-09-21 21:28:21	0|BlueMatt|eg pruning/bloom/etc cannot be turned on and off at runtime
530 2016-09-21 21:28:28	0|instagibbs|mind if i put a comment on that field to make that explicit? Maybe fewer tears in future
531 2016-09-21 21:28:28	0|sipa|agree, it's always set at startup
532 2016-09-21 21:28:43	0|BlueMatt|please do
533 2016-09-21 21:28:52	0|sipa|i'm making hypotheses here, cfields should probably comment
534 2016-09-21 21:29:04	0|BlueMatt|i dont think its new/changed in CConMan
535 2016-09-21 21:29:07	0|instagibbs|that was mine as well, but I'll wait for "official" call
536 2016-09-21 21:30:07	0|sipa|BlueMatt: before connman nLocalServices was a global
537 2016-09-21 21:32:31	0|instagibbs|I have a feeling reviewing cb pull will make a lot more sense now
538 2016-09-21 21:47:43	0|murch1|gmaxwell: 10 sat per byte, and for P2WPKH 10 byte per weight (if that's bytes + byte/4 for the witness part)
539 2016-09-21 21:48:39	0|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.
540 2016-09-21 21:49:47	0|sipa|murch1: sounds right
541 2016-09-21 21:51:15	0|gmaxwell|murch1: does your model for core convert dust to fees?
542 2016-09-21 21:56:07	0|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.
543 2016-09-21 21:56:48	0|gmaxwell|::sigh::
544 2016-09-21 21:57:06	0|gmaxwell|murch1: okay, well your efforts then are moving things into a realm of academic novelty rather than anything pratical then.
545 2016-09-21 21:57:25	0|sipa|gmaxwell, murch1: i believe you are misunderstanding each other
546 2016-09-21 21:58:18	0|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.
547 2016-09-21 21:58:54	0|sipa|how is the rule to convert dust to fees at all related to address reuse?
548 2016-09-21 21:59:27	0|gmaxwell|sipa: murch1 was responding to my earlier comment, not the most recent question about dust->fees..
549 2016-09-21 21:59:34	0|sipa|ah
550 2016-09-21 22:01:39	0|sipa|gmaxwell: he is currently moddelling how actual wallets work... that seems very practically useful and not an academic novelty
551 2016-09-21 22:02:14	0|sipa|sure, if we're trying to find an optimal strategy, it may be worth taking reuse into account
552 2016-09-21 22:04:35	0|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.
553 2016-09-21 22:04:58	0|sipa|i believe that's correct
554 2016-09-21 22:05:52	0|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)
555 2016-09-21 22:06:08	0|gmaxwell|I'd be interested in knowing how the results change if it will send dust to fees more agressively.
556 2016-09-21 22:06:18	0|sipa|yup
557 2016-09-21 22:06:39	0|sipa|it's already pretty aggressive
558 2016-09-21 22:06:46	0|gmaxwell|e.g. try a direct match, send dust change to fees. Only try targeting 0.01 btc change if that fails.
559 2016-09-21 22:07:34	0|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?
560 2016-09-21 22:07:42	0|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.
561 2016-09-21 22:09:09	0|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.
562 2016-09-21 22:09:26	0|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.
563 2016-09-21 22:09:44	0|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………
564 2016-09-21 22:10:58	0|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.
565 2016-09-21 22:12:33	0|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
566 2016-09-21 22:13:03	0|gmaxwell|yea, well I saw you were working off real data, so I had my hopes up. :P
567 2016-09-21 22:13:16	0|sipa|murch1: another idea may be to tie the minimum change to a percentage of the sent amount
568 2016-09-21 22:13:33	0|murch1|gmaxwell: The dataset is only positive and negative integers. Not even the order is actually really correct.
569 2016-09-21 22:13:58	0|murch1|because outgoing payments get recorded when requested and incoming only after confirmed.
570 2016-09-21 22:14:13	0|murch1|I have no clue when the transactions occurred or anything about addresses. :(
571 2016-09-21 22:15:26	0|gmaxwell|well, sensible wallets will not spend unconfirmed coins from third parties, so that ordering sounds basically correct.
572 2016-09-21 22:15:44	0|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.
573 2016-09-21 22:17:16	0|luke-jr|what is the purpose of share/qt/protobuf.pri?
574 2016-09-21 22:18:16	0|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.
575 2016-09-21 22:18:32	0|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.
576 2016-09-21 22:18:53	0|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.
577 2016-09-21 22:19:32	0|sipa|murch1: but that does depend on the order of magnitude of the amounts you are dealing with
578 2016-09-21 22:19:43	0|murch1|true
579 2016-09-21 22:19:50	0|sipa|someone who regularly receives and sends small amounts may want a smaller setting for that
580 2016-09-21 22:19:55	0|murch1|I'm still working of the same MoneyPot dataset.
581 2016-09-21 22:20:06	0|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.
582 2016-09-21 22:20:17	0|murch1|kanzure: Thanks
583 2016-09-21 22:21:57	0|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?
584 2016-09-21 22:22:11	0|murch1|on Linux?
585 2016-09-21 22:22:34	0|murch1|You probably meant the message to gmaxwell before?
586 2016-09-21 22:25:11	0|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.
587 2016-09-21 22:25:32	0|sipa|murch1: irssi
588 2016-09-21 22:25:38	0|murch1|gmaxwell: If the message was cut off before.
589 2016-09-21 22:25:49	0|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.
590 2016-09-21 22:25:49	0|sipa|used it exclusively for over 10 years now
591 2016-09-21 22:25:55	0|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.
592 2016-09-21 22:26:00	0|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.
593 2016-09-21 22:27:00	0|kanzure|((well also the general benefit that everyone receives from good coin selection everywhere.))
594 2016-09-21 22:34:05	0|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.
595 2016-09-21 22:34:15	0|murch_|sipa: did you see that about DoubleWallet?
596 2016-09-21 22:37:17	0|luke-jr|ugh, we added unlicensed-or-GPL code to master (and soon 0.13..)
597 2016-09-21 22:44:57	0|GitHub177|[13bitcoin] 15MarcoFalke opened pull request #8783: [share] remove qt/protobuf.pri (06master...06Mf1609-deleteqtProto) 02https://github.com/bitcoin/bitcoin/pull/8783
598 2016-09-21 22:56:57	0|warren|luke-jr: where?
599 2016-09-21 22:57:12	0|luke-jr|warren: l_atomic.m4
600 2016-09-21 22:57:24	0|luke-jr|author is okay with licensing it under MIT-like terms, so workign on that
601 2016-09-21 22:58:00	0|warren|great
602 2016-09-21 23:12:26	0|GitHub136|[13bitcoin] 15luke-jr opened pull request #8784: Copyright headers for build scripts (06master...06license_build) 02https://github.com/bitcoin/bitcoin/pull/8784