19:02:13 #startmeeting 19:02:13 Meeting started Thu Jan 4 19:02:13 2018 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:32 Meeting request: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag 19:02:37 Any topics? 19:02:43 hi. 19:02:53 hi 19:02:58 yet another quick codesigning update 19:03:07 #topic code signing 19:03:41 I've got the csr patching worked out, and gmaxwell is currently working on documenting the keygen process 19:03:54 nice! 19:04:05 Ideally we'd get that worked out in the next few days 19:04:34 Good. I think there is no need for rush things,... ideally, we would have the new cert for the 0.16 (or say 16.) release 19:04:36 jonasschnelli: is apple's signing process automated and pretty quick, i hope? 19:04:49 Do we have a new Apple cert? It expires in a few days 19:04:51 jonasschnelli: well the current cert expires on the 11 19:04:52 cfields: once we have the csr, ... it's a matter of seconds 19:05:05 achow101: we don't need it until 0.16 19:05:07 achow101: expiring only matter for new binaries 19:05:11 it's not a huge issue as we're not ready to release yet, ofc 19:05:17 right 19:05:22 meshcollider: jonasschnelli right, duh 19:05:31 I'd still like to avoid a lapse if possible, though 19:05:47 note that we also have the actual signing process to deal with 19:05:48 yes. In "emergency" cases, we can still create a single-person RSA cert... 19:05:49 although sooner is better. otherwise it becomes a release blocker 19:06:12 luckily I hacked up the mac codesigner last year, but it needs a bit of polish 19:06:27 achow101: Yes. Though we have the fallback doing the same as we already did (single person RSA cert) 19:07:01 How about Windows? 19:07:04 the only snag is that it doesn't handle timestamping. So worst-case, we may do a non-timestamped 0.16. It could be followed up with a timestamped release once that's worked out 19:07:24 Timestamping of what? 19:07:32 imo we should go ahead and do Windows once we've gone though the process for osx and identified the kinks 19:08:05 I have no insights how Windows code signing works... but probably the same RSA approach could be taken, right? 19:08:10 windows uses a free/open-source signer though, so that's no concern 19:08:26 yea, ideally we'd use the same procedure for both 19:08:30 * jonasschnelli curses apple closed source signing 19:08:59 it's possible that it's just an hour's worth of work. I just haven't looked into apple's timestamping mechanism yet 19:09:59 ok, that's it from me 19:10:13 thanks for the update! Thanks for working on this cfields 19:10:17 Any other topics? 19:10:40 coin selection 19:10:52 Hi :) 19:10:53 #topic coin selection (murchs algo) 19:11:06 Perfect timing Murch ;) 19:11:11 heh 19:11:17 Highlight on "coin selection" ;) 19:11:26 I did a bunch of simulations https://github.com/bitcoin/bitcoin/pull/10637#issuecomment-353989346 19:11:37 I'm not quite sure how to interpret the results 19:12:20 but it basically looks like it performs no worse than the current algo 19:12:24 Maybe Murch can comment on your results? 19:12:32 It looks like it usually does slightly better since BnB is hit a small percentage of the time 19:13:02 achow101: If you're only simulating flat fees the only thing that you're counting is the number of transactions that don't create a change output. 19:13:36 Murch: I've only simulated flat fee so far. Maybe I should try it with somehow using mainnet fee estimation? 19:14:12 achow101: What would be really interesting is whether the different selection algorithm has an impact on the cost in varying fee levels, because it could cause BnB to select more unspents at a higher fee level and fewer at a lower level, which would only be visible in a scenario of varying fee levels. 19:14:25 If people would like to run their own simulations, the code for it is available here: https://github.com/achow101/bitcoin/tree/bnb-simulate. More info in this commnet: https://github.com/bitcoin/bitcoin/pull/10637#issuecomment-353452113 19:14:41 That's at least my main concern in regard to deploying BnB. 19:15:25 Murch: I did run the simulation at different flat fee rates 19:15:29 Vaguely related question: is it possible to refactor the coin selection algo into a pure function that takes whatever info it needs (coins, mempool stats, etc) as input and returns the coins? That might make it easier to try different algos. 19:15:30 *simulations 19:16:25 achow101: Yes, I see that. But the selection effect would only be visible in a scenario with changing fees. 19:16:28 provoostenator: also in the past, there where discussions about having multiple coin selection 19:16:35 *selections 19:16:51 Right, that would be the idea. Easier to add more experimental selection mechanisms. 19:16:55 Murch: ah, right 19:17:06 provoostenator, standard coin selection right now is a loopy affair, kind of complicated :/ 19:17:30 provoostenator: achow101's implementation does a big step in that direction . 19:18:18 other topics? 19:18:51 @achow101: The table seems to show only the final UTXO count, right? 19:19:17 Interesting would also be the final balance of the wallet, especially in regard to the scenario with varying fee levels. 19:19:18 Murch: it shows all of the same things that your simulation framework outputs 19:19:20 I think 19:19:44 It's a big table, you'll have to scroll 19:19:54 Perhaps we could put our heads together in the next few days. 19:20:11 ok 19:20:22 Great work there, though thank you! 19:20:36 Yes. Thanks achow101! 19:20:37 provoostenator: So basically you pass in a higher order function to the actual 'read from wallet' function 19:21:55 Other topics? 19:22:25 merge fest? 19:23:22 Maybe after SegWit UI is merged? 19:23:42 I'm talking about that one :) 19:23:42 (I mean SegWit wallet) 19:24:01 Soon. :) 19:24:02 #endmeeting