1 2016-04-20T00:13:32  *** AaronvanW has joined #bitcoin-core-dev
  2 2016-04-20T00:13:33  *** AaronvanW has joined #bitcoin-core-dev
  3 2016-04-20T00:53:50  *** TomMc has joined #bitcoin-core-dev
  4 2016-04-20T00:54:34  <kanzure> sipa: there is some minor doubled text at the start of your issue comment, https://github.com/bitcoin/bitcoin/pull/7910#issuecomment-211998958
  5 2016-04-20T00:54:54  <kanzure> well, nearly.
  6 2016-04-20T01:13:00  *** Ylbam has quit IRC
  7 2016-04-20T01:17:52  *** frankenmint has quit IRC
  8 2016-04-20T01:29:13  *** frankenmint has joined #bitcoin-core-dev
  9 2016-04-20T01:30:05  *** dermoth_ has quit IRC
 10 2016-04-20T01:30:41  *** dermoth_ has joined #bitcoin-core-dev
 11 2016-04-20T01:41:47  <kanzure> "The must be at least one output whose scriptPubKey is a single 36-byte push" word missing?
 12 2016-04-20T01:45:38  *** aquentson1 has joined #bitcoin-core-dev
 13 2016-04-20T01:46:54  *** aquentson has quit IRC
 14 2016-04-20T01:56:24  *** shangzhou has joined #bitcoin-core-dev
 15 2016-04-20T01:58:13  *** PaulCapestany has quit IRC
 16 2016-04-20T01:58:34  *** PaulCapestany has joined #bitcoin-core-dev
 17 2016-04-20T01:58:35  <phantomcircuit> sipa: there three preparation commits in 7910 seem like they could be separe pr's
 18 2016-04-20T01:58:47  <phantomcircuit> (and appear to be trivial to review as such)
 19 2016-04-20T01:59:06  <phantomcircuit> as well as the "don't check genesis block" commit
 20 2016-04-20T01:59:16  <phantomcircuit> any reason they aren't proposed as separate pr's?
 21 2016-04-20T02:06:55  *** Chris_Stewart_5 has quit IRC
 22 2016-04-20T02:07:12  *** Giszmo has quit IRC
 23 2016-04-20T02:22:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 24 2016-04-20T02:26:47  *** mrkent_ has quit IRC
 25 2016-04-20T02:34:04  *** Chris_Stewart_5 has quit IRC
 26 2016-04-20T02:45:08  *** PaulCapestany has quit IRC
 27 2016-04-20T02:45:37  *** PaulCapestany has joined #bitcoin-core-dev
 28 2016-04-20T02:48:33  *** jtimon has quit IRC
 29 2016-04-20T02:58:03  *** PaulCapestany has quit IRC
 30 2016-04-20T02:58:31  *** PaulCapestany has joined #bitcoin-core-dev
 31 2016-04-20T03:14:01  *** gevs has quit IRC
 32 2016-04-20T03:21:39  *** arubi has quit IRC
 33 2016-04-20T03:22:20  *** PaulCapestany has quit IRC
 34 2016-04-20T03:22:45  *** PaulCapestany has joined #bitcoin-core-dev
 35 2016-04-20T03:25:44  *** gevs has joined #bitcoin-core-dev
 36 2016-04-20T03:39:09  *** TomMc has quit IRC
 37 2016-04-20T03:51:49  *** nhancm has joined #bitcoin-core-dev
 38 2016-04-20T03:53:39  *** nhancm_ has joined #bitcoin-core-dev
 39 2016-04-20T03:57:35  *** nhancm has quit IRC
 40 2016-04-20T04:02:01  *** Alopex has quit IRC
 41 2016-04-20T04:03:06  *** Alopex has joined #bitcoin-core-dev
 42 2016-04-20T04:08:11  *** shangzhou has quit IRC
 43 2016-04-20T04:09:42  *** achow101 has quit IRC
 44 2016-04-20T04:10:40  *** afk11 has quit IRC
 45 2016-04-20T04:10:44  *** PaulCapestany has quit IRC
 46 2016-04-20T04:11:07  *** PaulCapestany has joined #bitcoin-core-dev
 47 2016-04-20T04:11:49  *** isis has quit IRC
 48 2016-04-20T04:15:25  *** afk11 has joined #bitcoin-core-dev
 49 2016-04-20T04:18:32  *** nhancm__ has joined #bitcoin-core-dev
 50 2016-04-20T04:18:51  *** isis has joined #bitcoin-core-dev
 51 2016-04-20T04:21:43  *** nhancm_ has quit IRC
 52 2016-04-20T04:28:02  *** Alopex has quit IRC
 53 2016-04-20T04:29:07  *** Alopex has joined #bitcoin-core-dev
 54 2016-04-20T04:43:55  *** PaulCapestany has quit IRC
 55 2016-04-20T04:44:16  *** PaulCapestany has joined #bitcoin-core-dev
 56 2016-04-20T04:44:44  *** nhancm_ has joined #bitcoin-core-dev
 57 2016-04-20T04:48:04  *** nhancm__ has quit IRC
 58 2016-04-20T05:23:53  *** cryptocoder has quit IRC
 59 2016-04-20T05:28:07  *** cryptocoder has joined #bitcoin-core-dev
 60 2016-04-20T05:31:45  *** xabbix_ has joined #bitcoin-core-dev
 61 2016-04-20T05:32:57  *** xabbix__ has quit IRC
 62 2016-04-20T05:34:51  <NicolasDorier> question: during a sync headers first. chainActive is updated to the last block first when it received the header chain then rewinded if a block is incorrect, or does chainActive is updated as blocks are verified ?
 63 2016-04-20T05:40:05  *** BashCo has quit IRC
 64 2016-04-20T05:46:13  *** mrkent_ has joined #bitcoin-core-dev
 65 2016-04-20T05:54:58  *** PaulCapestany has quit IRC
 66 2016-04-20T05:57:58  *** PaulCapestany has joined #bitcoin-core-dev
 67 2016-04-20T06:00:16  *** dermoth_ has quit IRC
 68 2016-04-20T06:01:00  *** dermoth_ has joined #bitcoin-core-dev
 69 2016-04-20T06:01:08  *** paveljanik has quit IRC
 70 2016-04-20T06:09:46  *** BashCo has joined #bitcoin-core-dev
 71 2016-04-20T06:42:01  *** mrkent_ has quit IRC
 72 2016-04-20T06:48:02  *** Ylbam has joined #bitcoin-core-dev
 73 2016-04-20T07:04:30  *** pedrobranco has joined #bitcoin-core-dev
 74 2016-04-20T07:06:30  *** pedrobranco has quit IRC
 75 2016-04-20T07:17:02  *** Guyver2 has joined #bitcoin-core-dev
 76 2016-04-20T07:24:28  *** Lightsword has quit IRC
 77 2016-04-20T07:24:39  *** TD-Linux has quit IRC
 78 2016-04-20T07:25:20  *** Lightsword has joined #bitcoin-core-dev
 79 2016-04-20T07:25:48  *** TD-Linux has joined #bitcoin-core-dev
 80 2016-04-20T07:30:57  *** aquentson1 has quit IRC
 81 2016-04-20T07:38:39  *** sanada has joined #bitcoin-core-dev
 82 2016-04-20T08:11:48  <sipa> NicolasDorier: chainActive is the best known fully validated chain
 83 2016-04-20T08:14:28  <NicolasDorier> thanks
 84 2016-04-20T08:15:00  <sipa> phantomcircuit: they are
 85 2016-04-20T08:27:16  *** cryptocoder has quit IRC
 86 2016-04-20T08:28:27  *** paveljanik has joined #bitcoin-core-dev
 87 2016-04-20T08:35:16  *** nhancm__ has joined #bitcoin-core-dev
 88 2016-04-20T08:38:19  *** nhancm_ has quit IRC
 89 2016-04-20T08:54:14  *** pedrobranco has joined #bitcoin-core-dev
 90 2016-04-20T08:56:20  *** pedrobranco has quit IRC
 91 2016-04-20T08:56:27  *** pedrobranco has joined #bitcoin-core-dev
 92 2016-04-20T08:57:10  *** murch has joined #bitcoin-core-dev
 93 2016-04-20T08:58:19  <sipa> phantomcircuit: they're in #7749
 94 2016-04-20T09:00:48  <murch> btcdrak: I saw that you last updated the SegWit adoption overview: https://bitcoincore.org/en/segwit_adoption/ A lot of discussion had been linking to that table, is there a way that one could get a status update by the other projects, so that the table is up-to-date as SegWit discussion recommences right now?
 95 2016-04-20T09:01:59  <btcdrak> murch: they can submit a pull request https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_includes/pages/segwit_support.md
 96 2016-04-20T09:02:32  <btcdrak> as well as https://github.com/bitcoin-core/bitcoincore.org/blob/gh-pages/_posts/en/pages/2016-01-13-segwit-support.md
 97 2016-04-20T09:02:56  <sipa> hi murch!
 98 2016-04-20T09:03:03  <murch> Hi sipa :)
 99 2016-04-20T09:04:35  <murch> btcdrak: What I meant, is there some sort of communication channel that could be useful to get companies to check if they should be updating their status on the table? I think it would help show that secondary work on SegWit is progressing.
100 2016-04-20T09:05:22  <btcdrak> murch not sure I follow you.
101 2016-04-20T09:07:30  <murch> btcdrak: E.g. adam3us has referred to the table 16 days ago (https://www.reddit.com/r/Bitcoin/comments/4d3pdg/clearing_the_fud_around_segwit/d1nxxq6) as showing that secondary projects are working on SegWit. I've called him out on that, because the table doesn't actually show that. (I'm Xekyo on reddit). I would like to propose that development teams listed on that table get nudged to update their status, because it is my understanding
102 2016-04-20T09:08:31  <murch> The table is still the same as 16 days ago. :)
103 2016-04-20T09:10:54  <murch> My intent is to point out an easy improvement that could be made in the communication with the broader Bitcoin community. Unless I'm mistaken and the table is up-to-date. Then I'll rest my case of course. ;)
104 2016-04-20T09:11:08  <gmaxwell> You shouldn't expect it to change much until it's out there in the network. For anything not a full node there is no use in having it ready ahead of the network; so so I would expect most things to be in a working on it state for a bit yet.
105 2016-04-20T09:11:20  *** PaulCape_ has joined #bitcoin-core-dev
106 2016-04-20T09:13:59  *** PaulCapestany has quit IRC
107 2016-04-20T09:17:02  <murch> Okay, I guess I'm mistaken then.
108 2016-04-20T09:17:21  <sipa> i think it's good in general to ask teams to keep updating their status
109 2016-04-20T09:17:38  <sipa> "in progress" can mean a lot of things
110 2016-04-20T09:17:51  <sipa> and there could be a "Ready to rollout whenever the network is ready"
111 2016-04-20T09:17:54  <gmaxwell> Indeed, but probably in the form of getting something more granular than in progress.
112 2016-04-20T09:18:20  <gmaxwell> like ... "in tested on segnet/testnet"
113 2016-04-20T09:20:45  <murch> Completely different topic: I'm going to have a meeting later today about a potential master thesis in the area of Bitcoin. I've proposed to do my master thesis on Coin Selection (which I've did some simulation work before, e.g. gmaxwell had commented then). I've seen that CoinSelection is scheduled to be "looked at" for 0.13. Do you think it would make sense to have a more systematic analysis of CoinSelection even though that's schedu
114 2016-04-20T09:22:09  <sipa> I don't think you should see that "looked at" as anything more than that, and certainly not a promise that it will be investigated thoroughly or overhauled :)
115 2016-04-20T09:22:21  <sipa> And further analysis would be very useful.
116 2016-04-20T09:22:33  <sipa> For example,
117 2016-04-20T09:22:46  <murch> Cool, because I'd like to work on something useful for my thesis. :)
118 2016-04-20T09:23:09  <gmaxwell> it's tagged as to be looked at because were in need of some stopgap because the behehavior now is not great. But I don't think we're planning on doing much more than a bandaid.
119 2016-04-20T09:23:34  <sipa> creating multiple change outputs is an open question (when to do it, how to do it, what effects it has on the UTXO set in your wallet, and potentially indirectly the size of created transactions)
120 2016-04-20T09:24:27  <murch> sipa: Oh, interesting. I hadn't thought of that. But, shouldn't transactions aim to create the least necessary new UTXO?
121 2016-04-20T09:25:19  <sipa> murch: there are 2 reasons i know of to create multiple outputs: 1) privacy (if one of the change outputs looks identical to at least one of the payments, you can't tell anymore which of the outputs is the real change)
122 2016-04-20T09:25:58  <sipa> murch: another is that it may result in a more balanced set of wallet UTXOs to pick from, and that that may result in better coin selection for future transactions
123 2016-04-20T09:27:05  <murch> sipa: Yeah, one of my proposed algorithms then tried to create change of similar size to the target instead of "smallest possible". That's definitely an avenue I'd like to further investigate.
124 2016-04-20T09:27:26  <sipa> another question: does preferably picking outputs sent to the same address whenever one such output is already used (because you've payed the privacy tax already) help?
125 2016-04-20T09:27:59  <sipa> it's a complicated problem, because its priorities are unclear: privacy of address linkage, current transaction size, and future transaction sizes
126 2016-04-20T09:30:23  <murch> Yeah, that's why I think it's a good topic for a thesis. You can try a lot of different things, you can simulate and model it well, and finding a better solution might benefit the project. :) Anyway, I'm glad I asked, because I felt that the topic might become obsolete with the SegWit discount and the scheduled review.
127 2016-04-20T09:30:55  <gmaxwell> no, not at all.
128 2016-04-20T09:31:00  <sipa> segwit should be orthogonal
129 2016-04-20T09:31:09  <sipa> all it does is change the cost metric for computing fees
130 2016-04-20T09:31:12  <murch> sipa: I'll have to see if I can find more information on the occurrence of address reuse.
131 2016-04-20T09:32:00  <murch> sipa: Yeah, but I was afraid that the small changeset that was finally adopted from my last CoinSelection push has even made UTXO growth worse
132 2016-04-20T09:32:21  <murch> gmaxwell: Great! :)
133 2016-04-20T09:33:15  <sipa> from an email i have from satoshi over 5 years ago:
134 2016-04-20T09:33:18  <sipa> Another case is breaking large change outputs into two random sizes to increase backup safety so you're not rewriting your entire savings in every transaction.  It would create more varied sizes for SelectCoins to choose from in the future.  Some may also want to do it to smooth out priority use or increase privacy wrt the amounts.
135 2016-04-20T09:33:18  <gmaxwell> murch: yes, I believe it has; but thats not your fault. We discussed it then.
136 2016-04-20T09:33:27  <murch> the pruning of inputs was added then, although my simulation hadn't conclusively shown that it would be an improvement, and I'm afraid that it contributes by keeping small UTXO from being consolidated now
137 2016-04-20T09:33:39  *** grimescapes has quit IRC
138 2016-04-20T09:34:05  <gmaxwell> sipa: I think we should always split by default at some threshold.. it's silly to make outputs which are hundreds of btc or more.
139 2016-04-20T09:35:08  <sipa> but for example: what if you have the choice between making an tiny change output (close to dust, unlikely to be used ever) and adding an extra input and creating two outputs (one of which is similar to the payment)
140 2016-04-20T09:35:15  <sipa> should you do that or not
141 2016-04-20T09:35:27  <sipa> eh, creating two change outputs
142 2016-04-20T09:35:39  <murch> also an interesting thought. I had been considering an approach of #inputs should be greater than #outputs, but you really don't want to tell the recipient your whole balance every time. Anyway, I'm assuming that I'll be investing considerable effort to create a fitness function for evaluation
143 2016-04-20T09:36:06  <sipa> oh, there is a way in which segwit may be relevant: adding an extra input will be cheaper than adding an extra output
144 2016-04-20T09:36:33  <gmaxwell> well there will also be the added complication from aggregation in the not that distant future.
145 2016-04-20T09:36:38  <murch> sipa: I thought it would make the two about equally expensive?
146 2016-04-20T09:36:44  <gmaxwell> Where its much cheaper to spend more inputs at once.
147 2016-04-20T09:37:18  <gmaxwell> sipa: it's about equal because of the witness costs of the additional input (id selection)
148 2016-04-20T09:37:46  * sipa opens spreadsheet
149 2016-04-20T09:37:48  <murch> another question: Will Schnorr signatures not make inputs vastly cheaper, as the signatures can be combined? Wouldn't that also help consolidate the UTXO set? When would we be expecting a switch to Schnorr?
150 2016-04-20T09:38:20  <sipa> murch: the effect of Schnorr isn't that large anymore after segwit
151 2016-04-20T09:38:29  <murch> I see, thanks.
152 2016-04-20T09:38:32  <sipa> (if you're talking about transaction-wide aggregation)
153 2016-04-20T09:39:04  <murch> I believe I was. :)
154 2016-04-20T09:39:21  <gmaxwell> sipa: thats now getting called schnorr signatures due to that article. :(
155 2016-04-20T09:39:34  <sipa> https://docs.google.com/spreadsheets/d/1TvWBvjAAiVOBUgbYuuQ4rWnMQLXxI3qlMXVWhCdAtSw
156 2016-04-20T09:40:16  <murch> Thank you so much for the input, that'll help me later in my meeting with my (hopefully) future advisor convince him that it's a relevant topic. :D
157 2016-04-20T09:40:39  <sipa> murch: where are you studying?
158 2016-04-20T09:40:51  <murch> sipa: Karlsruhe Institute of Technology
159 2016-04-20T09:41:11  <sipa> ha, nice; i'm in stuttgart currently
160 2016-04-20T09:41:17  <sipa> that's pretty close i think
161 2016-04-20T09:41:26  <murch> Yeah, it is. I thought you were in Switzerland?
162 2016-04-20T09:41:33  <sipa> it's complicated :)
163 2016-04-20T09:42:07  <sipa> but i'll be here a lot the next month/months
164 2016-04-20T09:45:42  *** MarcoFalke has joined #bitcoin-core-dev
165 2016-04-20T09:47:17  <murch> I'd love to grab a beer with you sometime. Perhaps throw around a few more ideas about my thesis once I'm further along. :)
166 2016-04-20T09:47:27  <sipa> sure!
167 2016-04-20T09:47:56  <murch> Do I remember correctly that I've read somewhere that you enjoy rock climbing? ^^
168 2016-04-20T09:48:10  <sipa> i believe that's petertodd
169 2016-04-20T09:48:32  <gmaxwell> actually petertodd does caves. rock climbing is too safe.
170 2016-04-20T09:48:38  <murch> ah, nevermind then. :D
171 2016-04-20T09:48:59  <gmaxwell> (maybe he also does rockclimbing, but certantly more caves)
172 2016-04-20T09:49:07  <sipa> he's a miner, after all
173 2016-04-20T09:49:14  <kinlo> :p
174 2016-04-20T09:49:39  <gmaxwell> ::groan::
175 2016-04-20T09:49:49  <gmaxwell> I think not anymore.
176 2016-04-20T09:50:12  <murch> sipa: We've actually met once (very briefly) at Bitcoin 2014. :) I said hi, and told you that I'm a moderator on Bitcoin.SE. and you said, you love our work. Heh.
177 2016-04-20T09:50:34  <murch> Thanks guys, you just made my day.
178 2016-04-20T09:54:16  *** Thireus1 has quit IRC
179 2016-04-20T09:55:46  *** Thireus has joined #bitcoin-core-dev
180 2016-04-20T10:00:13  *** aquentson has joined #bitcoin-core-dev
181 2016-04-20T10:13:04  *** jannes has joined #bitcoin-core-dev
182 2016-04-20T10:18:41  *** murch has quit IRC
183 2016-04-20T10:19:54  *** nhancm__ has quit IRC
184 2016-04-20T10:38:42  <GitHub185> [bitcoin] venatici opened pull request #7914: [qa] Add optional unique coinbase generation (master...coinbase) https://github.com/bitcoin/bitcoin/pull/7914
185 2016-04-20T10:40:34  *** sanada has left #bitcoin-core-dev
186 2016-04-20T10:40:43  *** sanada has joined #bitcoin-core-dev
187 2016-04-20T10:52:52  *** achow101 has joined #bitcoin-core-dev
188 2016-04-20T11:02:01  *** zlover has joined #bitcoin-core-dev
189 2016-04-20T11:36:35  <zlover> Hi
190 2016-04-20T11:46:42  *** jtimon has joined #bitcoin-core-dev
191 2016-04-20T11:53:46  *** cryptapus has joined #bitcoin-core-dev
192 2016-04-20T12:36:23  *** randy-waterhouse has quit IRC
193 2016-04-20T12:54:17  *** cryptapus__ has joined #bitcoin-core-dev
194 2016-04-20T12:57:44  *** cryptapus has quit IRC
195 2016-04-20T13:02:43  *** zooko has quit IRC
196 2016-04-20T13:16:44  *** mr_burdell has joined #bitcoin-core-dev
197 2016-04-20T13:17:03  *** Guest25495 has quit IRC
198 2016-04-20T13:17:23  *** Lightsword has quit IRC
199 2016-04-20T13:18:41  *** windsok has quit IRC
200 2016-04-20T13:18:45  *** schmidty has quit IRC
201 2016-04-20T13:19:34  *** windsok has joined #bitcoin-core-dev
202 2016-04-20T13:19:50  *** Lightsword has joined #bitcoin-core-dev
203 2016-04-20T13:21:08  *** zooko has joined #bitcoin-core-dev
204 2016-04-20T13:22:25  <GitHub149> [bitcoin] hmel opened pull request #7916: Explicitly pass CChainParams& to DisconnectTip() (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/7916
205 2016-04-20T13:27:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
206 2016-04-20T13:31:35  <GitHub41> [bitcoin] jtimon closed pull request #7876: Globals: Explicitly pass const CChainParams& to UpdateTip() (master...0.12.99-globals-chainparams-updatetip) https://github.com/bitcoin/bitcoin/pull/7876
207 2016-04-20T13:42:13  *** face has joined #bitcoin-core-dev
208 2016-04-20T13:42:58  *** TomMc has joined #bitcoin-core-dev
209 2016-04-20T13:44:32  <jtimon> thank you face for participating in my little experiment in #7829 with your PR #7916 which I'm very happy with!
210 2016-04-20T13:47:49  *** zlover has quit IRC
211 2016-04-20T13:48:55  *** cryptapus__ is now known as cryptapus
212 2016-04-20T13:56:30  <face> jtimon, thank you for doing this. It's a great way to get potential devs to experience for real the dev workflow!
213 2016-04-20T14:13:19  <jtimon> face you are welcomed, that is entirely the point (that, and getting people to do want I want to get done Ha ha ha</evil_laughter>)
214 2016-04-20T14:13:34  <GitHub13> [bitcoin] sipa opened pull request #7917: Optimize reindex (master...betterreindex) https://github.com/bitcoin/bitcoin/pull/7917
215 2016-04-20T14:19:07  <jtimon> I'm sure I have done that stuff several times already myself, so I thought it would be more productive tol help potential new devs do it whenever they want rather than me rebasing all the time a branch that it's just too disruptive to be merged at once, while PRing many little commits separately is a good way for me to run out of rebase patience  (while making more noise with more PRs open)
216 2016-04-20T14:19:35  *** d_t has joined #bitcoin-core-dev
217 2016-04-20T14:30:37  *** zooko has quit IRC
218 2016-04-20T14:34:27  <helo> +1 wonderful
219 2016-04-20T14:34:31  *** cryptapus has quit IRC
220 2016-04-20T14:34:43  *** cryptapus has joined #bitcoin-core-dev
221 2016-04-20T14:42:24  *** zooko has joined #bitcoin-core-dev
222 2016-04-20T14:44:01  *** BashCo has quit IRC
223 2016-04-20T14:46:56  *** galileopy has quit IRC
224 2016-04-20T14:47:51  *** Guyver2 has quit IRC
225 2016-04-20T15:00:06  *** galileopy has joined #bitcoin-core-dev
226 2016-04-20T15:06:36  *** cryptapus is now known as cryptapus_
227 2016-04-20T15:06:40  *** JackH has joined #bitcoin-core-dev
228 2016-04-20T15:06:52  *** cryptapus_ is now known as cryptapus__
229 2016-04-20T15:07:08  *** cryptapus__ is now known as cryptapus
230 2016-04-20T15:07:53  *** BashCo has joined #bitcoin-core-dev
231 2016-04-20T15:09:11  *** baldur has quit IRC
232 2016-04-20T15:13:35  *** murch has joined #bitcoin-core-dev
233 2016-04-20T15:21:41  <paveljanik> MarcoFalke, do you have an issue for the wallet.py test?
234 2016-04-20T15:22:02  <sipa> cfields has been looking into it as well
235 2016-04-20T15:22:10  <paveljanik> I did a quick test yesterday and end up with db-> rename returning 2...
236 2016-04-20T15:22:43  <paveljanik> and I'm not able to reproduce the problem today 8)
237 2016-04-20T15:22:45  <MarcoFalke> Should be one of those tagged with "wallet": https://github.com/bitcoin/bitcoin/issues/created_by/MarcoFalke
238 2016-04-20T15:22:51  <murch> sipa: My master thesis' working title is "Evaluation of Coin Selection Strategies" ;)
239 2016-04-20T15:23:13  <MarcoFalke> nice
240 2016-04-20T15:23:14  <sipa> murch: nice
241 2016-04-20T15:23:25  <MarcoFalke> which field are you doing your masters in?
242 2016-04-20T15:23:30  <MarcoFalke> ec or cs?
243 2016-04-20T15:23:32  <murch> Computer Science
244 2016-04-20T15:24:33  <paveljanik> MarcoFalke, this particular issue seems to be different...
245 2016-04-20T15:25:10  <MarcoFalke> Did you save the log?
246 2016-04-20T15:25:53  <paveljanik> Once I started to run ./wallet.py --tracerpc --nocleanup in endless cycle, no error 8)
247 2016-04-20T15:26:07  <paveljanik> Probably only in the terminal scrollback buffer
248 2016-04-20T15:26:09  <paveljanik> 8(
249 2016-04-20T15:26:18  <paveljanik> I'm on it.
250 2016-04-20T15:27:21  <paveljanik> it would be nice to have --nocleanuponfail ;-)
251 2016-04-20T15:28:38  <sipa> --nocleanup exists
252 2016-04-20T15:28:52  <sipa> as well as --noshutdown
253 2016-04-20T15:38:38  <sipa> morcos: what do you think about https://github.com/sipa/bitcoin/pull/77/commits/9debcaf442f6705c3b08c9fffd5da2ff2116ba53?w=1 ?
254 2016-04-20T15:39:05  <sipa> morcos: if you negotiated in the version message to not send transactions, and then send a feefilter, it will start relaying txn
255 2016-04-20T15:59:30  <morcos> sipa: so this is just a way to have more flexibility, to allow turning sending of txs back on?
256 2016-04-20T16:00:21  <morcos> i don't think i have any issue with that concept, but i'm a bit hesitant on whether its worth the complication
257 2016-04-20T16:00:42  <morcos> for instance isn't there code to disconnect/ban peers that send you txs when you didnt' ask for them
258 2016-04-20T16:00:56  <morcos> is that corrected to account for this (haven't reviewed the whole pull)
259 2016-04-20T16:01:31  <sipa> well this is about sending invs, not getdata or tx
260 2016-04-20T16:02:08  <sipa> and it does make sense that if you want to use feefilter, you want to make sure that you first get to tell the peer what feefilter you want before he starts sending transactions
261 2016-04-20T16:02:24  <sipa> (same as with bip37 filters)
262 2016-04-20T16:03:18  <morcos> i'm confused, are you talking about for other implementations sending this (such as lite clients)?
263 2016-04-20T16:03:30  <sipa> yes
264 2016-04-20T16:03:51  <sipa> not that any of them do send feefilter right now
265 2016-04-20T16:04:08  <sipa> i'm just trying to guess why greg's adding a seemingly unrelated change here
266 2016-04-20T16:04:34  <morcos> i guess i never thought of feefilter as a strict requirement.  you aren't required to obey it, its only an approximation of where you actually want the cutoff to be, and there are unknown delays in sending it
267 2016-04-20T16:04:47  <morcos> ha ha, thats what i'm trying to guess
268 2016-04-20T16:06:07  <morcos> anyway, i don't see a problem with it, but i don't see a specific advantage either, and it seems to me that if we don't know of a use case where you want to start with no txs and then turn them back on later, that there is no reason to add this.
269 2016-04-20T16:06:42  <sipa> it's not that you'd want to start with no txs
270 2016-04-20T16:07:04  <sipa> it's that you don't want to be bombed with a torrent of txs before you've had a chance to tell your peer what fee filter you want
271 2016-04-20T16:07:32  <morcos> but you never get a torrent of invs
272 2016-04-20T16:07:45  <sipa> but there are arguments against it: 1) what if you want both a bip37 filter and a feefilter? sending either will turn on invs before sending the second
273 2016-04-20T16:07:48  <sipa> i know :)
274 2016-04-20T16:07:51  <morcos> and if you are doing something like a filtered block or mempool command then you have the choice to send the feefilter message before you ask for those
275 2016-04-20T16:09:12  <morcos> to be clear, i like the idea of moving the filtering to the end piece. it'll result in many more mempool lookups (once per inv), but i think thats ok
276 2016-04-20T16:10:09  <morcos> its  just tying it into the fRelayTxes variable that i don't see the point of.
277 2016-04-20T16:10:24  <sipa> ok
278 2016-04-20T16:15:08  <morcos> yeah in talking to sdaftuar, i don't really see the feefilter as analogous to the bip37filter.   feefilter seems almost unlikely to be used by lite clients, why would you not want to know about all relevant txs to you anyway, you can do your own logic if you dont' think the fees are high enough.  i see feefilter as a tool for full nodes to eliminate traffic that would be dropped at mempool acceptance anyway
279 2016-04-20T16:20:55  *** cryptocoder has joined #bitcoin-core-dev
280 2016-04-20T16:21:45  <jtimon> ping #7728, all nits resolved, I think
281 2016-04-20T16:25:29  <morcos> we don't guard the printing of IP address for incoming connections with fLogIPs.  is that intentional?
282 2016-04-20T16:31:19  *** cryptocoder_ has joined #bitcoin-core-dev
283 2016-04-20T16:33:27  *** cryptocoder has quit IRC
284 2016-04-20T16:33:28  *** cryptocoder_ is now known as cryptocoder
285 2016-04-20T16:34:44  <kanzure> i have completed my read-through of the segwit pull request, now on to organizing thoughts/notes/bugs...
286 2016-04-20T16:47:16  <GitHub21> [bitcoin] MarcoFalke opened pull request #7918: [qa] mininode: Use hexlify wrapper from util (master...Mf1604-qaMininodeHexlify) https://github.com/bitcoin/bitcoin/pull/7918
287 2016-04-20T17:06:48  *** arowser has quit IRC
288 2016-04-20T17:07:13  *** arowser has joined #bitcoin-core-dev
289 2016-04-20T17:19:52  *** Chris_Stewart_5 has quit IRC
290 2016-04-20T17:26:54  *** zooko has quit IRC
291 2016-04-20T17:49:01  *** zooko has joined #bitcoin-core-dev
292 2016-04-20T17:50:06  *** LeMiner2 has joined #bitcoin-core-dev
293 2016-04-20T17:52:22  *** LeMiner has quit IRC
294 2016-04-20T18:01:12  *** murch has quit IRC
295 2016-04-20T18:13:51  *** d_t has quit IRC
296 2016-04-20T18:22:46  *** Guyver2 has joined #bitcoin-core-dev
297 2016-04-20T18:26:38  <GitHub54> [bitcoin] sdaftuar opened pull request #7919: Fix headers announcements edge case (master...fix-sendheaders-edge-case) https://github.com/bitcoin/bitcoin/pull/7919
298 2016-04-20T18:29:00  *** pedrobranco has quit IRC
299 2016-04-20T18:30:59  *** pedrobranco has joined #bitcoin-core-dev
300 2016-04-20T18:35:16  *** pedrobranco has quit IRC
301 2016-04-20T18:37:23  <gmaxwell> sipa: why I was making it there was because I went to go fix the lack of locking on fRelayTX and then realized feefilter didn't trigger it, which surprised me.
302 2016-04-20T18:37:33  <gmaxwell> I've yanked out those changes.
303 2016-04-20T18:39:57  <sipa> thanks
304 2016-04-20T18:46:29  *** jannes has quit IRC
305 2016-04-20T18:47:26  <sipa> sdaftuar, morcos: did you see BlueMatt's proposal to treat non-connecting headers as invs, and go fetch it?
306 2016-04-20T18:48:33  *** pedrobranco has joined #bitcoin-core-dev
307 2016-04-20T18:48:35  <sdaftuar> sipa: i did.  i think that's a fine change to make, though i'd be wary of doing it too much, as part of the point of headers relay is to avoid the extra round trip to propagate a reorg
308 2016-04-20T18:49:09  <BlueMatt> sdaftuar: we can still be smart about what we send, but if another client doesnt want to implement that much and just wants to have a lazy protocol to announce we should be willing to recv smarter
309 2016-04-20T18:49:19  <sdaftuar> right, i agree with that
310 2016-04-20T18:49:28  <sipa> right, though i vaguely remember that there can be edge cases in which we can't orevent non-connecting headers
311 2016-04-20T18:50:03  <sdaftuar> oh, and you're suggesting that we just send the header anyway, rather then revert to inv?
312 2016-04-20T18:50:06  <sdaftuar> we could do that too
313 2016-04-20T18:50:51  <sdaftuar> there's not much benefit though i think?
314 2016-04-20T18:53:17  *** pedrobranco has quit IRC
315 2016-04-20T18:54:01  <sipa> i forget the whole discussion; i think it's more about us dealing well with others sending unconnecting headers
316 2016-04-20T18:56:52  <sdaftuar> AcceptBlockHeader will give a DoS (10) to a peer for sending a header with an unknown prev block
317 2016-04-20T18:59:26  <gmaxwell> My understanding of Matt's complaint is that this then forces you to do the rather complex tracking.
318 2016-04-20T18:59:45  <BlueMatt> it introduces a lot of required state in order to do sendheaders
319 2016-04-20T18:59:57  <BlueMatt> which seems kinda crazy to me since sendheaders is so conceptually simple
320 2016-04-20T19:03:45  *** d_t has joined #bitcoin-core-dev
321 2016-04-20T19:04:19  <sdaftuar> i don't really follow why a peer would choose to implement sendheaders if they weren't going to do the tracking.  how is it better than sending inv's, which are smaller?
322 2016-04-20T19:04:36  <sdaftuar> i do agree that we could handle unconnecting headers more gracefully though
323 2016-04-20T19:05:42  <BlueMatt> sdaftuar: i mean you know that sending headers to your peer is gonna make their download more effecient, so you'd prefer to, why not?
324 2016-04-20T19:06:10  <BlueMatt> having to track the current state of your peer's chain is so gross
325 2016-04-20T19:06:17  *** zooko has quit IRC
326 2016-04-20T19:06:27  <sdaftuar> we already mostly have to track the state of their chain, to avoid re-announcing blocks to them that they know about
327 2016-04-20T19:06:44  *** molz is now known as moli
328 2016-04-20T19:06:52  <sdaftuar> and to know which blocks we can download from them
329 2016-04-20T19:07:02  <BlueMatt> no we dont
330 2016-04-20T19:07:21  <BlueMatt> you can announce any shit you want and your peer will figure out if they want to request it or not
331 2016-04-20T19:07:41  <BlueMatt> it says nowhere in the protocol that you have to be reasonable about what you announce
332 2016-04-20T19:08:54  <BlueMatt> it also says nowhere that you have to download from all your peers or be a downloading peer in order to sendheaders
333 2016-04-20T19:08:57  <BlueMatt> or, at least, you shouldnt be
334 2016-04-20T19:09:22  <BlueMatt> not to mention its always been a general goal for the protocol to be as stateless as possible :/
335 2016-04-20T19:12:16  *** belcher has joined #bitcoin-core-dev
336 2016-04-20T19:16:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
337 2016-04-20T19:18:36  <sipa> BlueMatt: calm down
338 2016-04-20T19:18:50  <sipa> BlueMatt: sdaftuar was just saying that we are already tracking that anyway
339 2016-04-20T19:19:33  <BlueMatt> hmm? I'm not upset? anyway, point was that we're requiring other protocol implementors to track it...we arent the only ones who have to implement this protocol
340 2016-04-20T19:20:11  <sipa> yes, i'm aware of that
341 2016-04-20T19:20:24  <sipa> i don't think anyone is disagreeing with anyone else
342 2016-04-20T19:21:10  *** frankenmint has quit IRC
343 2016-04-20T19:22:00  <sipa> so the changes required would be 1) not DoS when unconnecting headers are received 2) trigger a getheaders in that case?
344 2016-04-20T19:23:19  <BlueMatt> I thought that was sufficient but went and did that and saw some cases where the resulting headers werent leading to chain sync, I didnt investigate why
345 2016-04-20T19:23:32  <BlueMatt> might have been unrelated bugs causing it, however
346 2016-04-20T19:48:30  *** mrkent_ has joined #bitcoin-core-dev
347 2016-04-20T19:54:40  *** molz has joined #bitcoin-core-dev
348 2016-04-20T19:57:30  *** moli has quit IRC
349 2016-04-20T20:10:44  *** mrkent_ has quit IRC
350 2016-04-20T20:21:57  *** frankenmint has joined #bitcoin-core-dev
351 2016-04-20T20:26:43  *** frankenmint has quit IRC
352 2016-04-20T20:27:36  *** galileopy has quit IRC
353 2016-04-20T20:31:34  *** paveljanik has quit IRC
354 2016-04-20T20:35:54  *** Chris_Stewart_5 has quit IRC
355 2016-04-20T20:47:49  *** cryptapus has quit IRC
356 2016-04-20T20:48:13  *** mrkent_ has joined #bitcoin-core-dev
357 2016-04-20T20:50:29  *** zooko has joined #bitcoin-core-dev
358 2016-04-20T21:02:13  *** frankenmint has joined #bitcoin-core-dev
359 2016-04-20T21:04:45  *** zooko` has joined #bitcoin-core-dev
360 2016-04-20T21:06:00  *** zooko has quit IRC
361 2016-04-20T21:07:25  *** frankenmint has quit IRC
362 2016-04-20T21:15:53  *** MarcoFalke has quit IRC
363 2016-04-20T21:22:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
364 2016-04-20T21:27:04  *** zooko` has quit IRC
365 2016-04-20T21:34:31  *** Giszmo has joined #bitcoin-core-dev
366 2016-04-20T21:35:57  *** pedrobranco has joined #bitcoin-core-dev
367 2016-04-20T21:43:12  *** pedrobranco has quit IRC
368 2016-04-20T21:48:02  *** pedrobranco has joined #bitcoin-core-dev
369 2016-04-20T22:04:44  *** pedrobranco has quit IRC
370 2016-04-20T22:08:19  *** Guyver2 has quit IRC
371 2016-04-20T22:13:57  <kanzure> sipa: i replied re: SignatureHash namecalling :) https://github.com/bitcoin/bips/pull/374#issuecomment-212632899
372 2016-04-20T22:15:06  *** d_t has quit IRC
373 2016-04-20T22:16:45  *** TomMc has quit IRC
374 2016-04-20T22:25:28  <sipa> kanzure: so did i :)
375 2016-04-20T22:29:16  *** SteveTaylor has quit IRC
376 2016-04-20T22:30:21  *** AaronvanW has quit IRC
377 2016-04-20T22:43:20  <kanzure> yes i know it's the hash being signed...
378 2016-04-20T22:43:30  <sipa> sorry :)
379 2016-04-20T22:43:37  <sipa> may not be obvious to everyone
380 2016-04-20T22:43:51  <kanzure> *shrug* hard thing to name anyway. i don't have any good ideas for that.
381 2016-04-20T22:44:16  <sipa> ComputeTransactionHashForSigning
382 2016-04-20T22:44:28  <kanzure> "but this is a different transaction hash, we promise"
383 2016-04-20T22:45:23  <kanzure> in some old source code i wrote, i called txid "txhash" because "well txid is a silly name" but now we're about to get a "transaction hash" in some rpc outputs heh
384 2016-04-20T22:45:25  <phantomcircuit> cfields, i'd like to add something like the benchmarking framework for fuzzing
385 2016-04-20T22:45:45  <phantomcircuit> i tried copy/pasting the benchmark stuff but i cant seem to get it to work
386 2016-04-20T22:46:14  <phantomcircuit> any chance you have spare cycles for this?
387 2016-04-20T22:46:59  <phantomcircuit> essentially just want to have a separate set of binaries which are fenced off by --enable-fuzzing
388 2016-04-20T22:47:17  *** Don_John has joined #bitcoin-core-dev
389 2016-04-20T22:47:47  <BlueMatt> heh, I didnt realize petertodd had posted the bribe-miners-to-do-aml shit on reddit/his blog
390 2016-04-20T22:52:00  *** Giszmo has quit IRC
391 2016-04-20T23:10:34  *** zooko has joined #bitcoin-core-dev
392 2016-04-20T23:19:43  *** Chris_Stewart_5 has quit IRC
393 2016-04-20T23:51:32  *** belcher has quit IRC