19:00:45 <wumpus> #startmeeting
19:00:45 <lightningbot> Meeting started Thu Mar 22 19:00:45 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:45 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:06 <provoostenator> Hi
19:01:13 <morcos> kind of here
19:01:14 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:01:20 <kanzure> hi.
19:01:22 <cfields> hi
19:01:24 <achow101> oh right, it's thursday
19:01:33 <wumpus> yep
19:01:37 <instagibbs> hi
19:01:52 <wumpus> any topic suggestions?
19:02:18 <BlueMatt> <topic suggestion>
19:02:22 <wumpus> #topic high priority for review
19:02:24 <ryanofsky> #11536
19:02:28 <gribble> https://github.com/bitcoin/bitcoin/issues/11536 | Rename account to label where appropriate by ryanofsky · Pull Request #11536 · bitcoin/bitcoin · GitHub
19:02:33 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:02:40 <meshcollider> Hi
19:03:12 <Randolf> Hello.
19:03:18 <wumpus> ryanofsky: anothing specific you want to discuss regarding that pr?
19:03:46 <ryanofsky> just curious about status, if it is ready to be merged or if it needs more review
19:03:51 <wumpus> anything that needs to be added/removed from high priority for review?
19:04:20 <wumpus> ryanofsky: makes sense
19:04:33 <sipa> i'll have a look in a minute
19:04:42 <Randolf> PR #12759 looks like it would be an easy one to merge quickly.
19:04:44 <gribble> https://github.com/bitcoin/bitcoin/issues/12759 | [Docs] Improve formatting of developer notes by eklitzke · Pull Request #12759 · bitcoin/bitcoin · GitHub
19:04:52 <wumpus> Randolf: that's not the topic though
19:04:56 <Randolf> Oh, sorry.
19:05:20 <wumpus> formatting of developer notes is not 'high priority for review' in any definition
19:05:22 <Randolf> I though you were asking if there was anything to add/remove for review.
19:05:28 <Randolf> I see.  Yes.
19:05:48 <wumpus> high priority for review description is: These either block other important work in progress, or are necessary for backport to a minor release.
19:06:18 <Randolf> Thank you.
19:06:29 <wumpus> if something can be merged it's better to let me know outside the meeting
19:06:39 <wumpus> anyhow, it seems people are happy with the current set, next topic
19:06:42 <provoostenator> Topic suggestion: Gitter (we talked about this recently as a way to lower barrier for new contributors, compared to IRC)
19:06:49 <jimpo> I've already got one in high pri for review list, but #11857 is more of a blocker for my work
19:06:53 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
19:07:04 <sipa> jimpo: agree that seems a better candidate for now
19:07:08 <wumpus> jimpo: swap it out?
19:07:13 <jimpo> Yep
19:07:35 <sipa> can i have #12714 on the list?
19:07:37 <gribble> https://github.com/bitcoin/bitcoin/issues/12714 | Introduce interface for signing providers by sipa · Pull Request #12714 · bitcoin/bitcoin · GitHub
19:07:45 <wumpus> jimpo: done
19:08:03 <wumpus> sipa: done
19:08:28 <wumpus> #topic Rename account to label where appropriate (ryanofsky)
19:08:51 <provoostenator> That PR seems more or less ready to go, right?
19:08:52 <wumpus> <ryanofsky> just curious about status, if it is ready to be merged or if it needs more review
19:09:06 <meshcollider> It has 3 tested acks and a utACK already, looks very close if not ready
19:09:08 <wumpus> ok!
19:09:14 <achow101> I thought that was supposed to go after #7729?
19:09:17 <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
19:09:18 <ryanofsky> yeah, i think it's ready
19:09:20 <achow101> or did I get the order backwards
19:09:31 <meshcollider> Yeah other way around achow101
19:09:33 <wumpus> if it's ready it should go in
19:09:39 <sipa> achow101: 12714 is just a first step taken out of 7729
19:09:46 <achow101> oh, ok
19:09:46 <sipa> topic suggestion: what's up with #12694 and next steps?
19:09:49 <gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
19:09:57 <meshcollider> Topic suggestion: EOL date for 0.13 ( https://github.com/bitcoin-core/bitcoincore.org/pull/528 )
19:10:29 <wumpus> #topic gitter (provoostenator)
19:10:44 <BlueMatt> it'd have to be mirrored to irc
19:10:56 <sipa> gitter has an IRC interface
19:10:57 <BlueMatt> bidirectionally, that is
19:11:09 <sipa> as in, you can connect to it as an IRC server
19:11:10 <BlueMatt> sipa: that requires we all move our bouncers, I think thats more than its worth
19:11:11 <wumpus> I've never used gitter, but I'm not going to join any more chat services
19:11:27 <sipa> well what's the context?
19:11:32 <luke-jr> what is it?
19:11:34 <sipa> i don't think we're planning to move this channel...
19:11:37 <BlueMatt> its my impression it can be bidirectionally mirrored to irc, which would be fine, but I'm not sure how much its worth
19:11:42 <Randolf> I've tried other chat services, and they're just not as good as IRC.
19:11:52 <BlueMatt> sipa: its some newfangled slack-like bullshit that is "for open source projects"
19:11:54 <wumpus> mirroring sounds fine to me, if ti doesn't increase the noise level too much
19:12:11 <sipa> BlueMatt: i know; i've used it for another project before and it works pretty well
19:12:18 <achow101> Isn't the idea to make it easier for people to start contributing?
19:12:20 <sipa> but i'm wondering why it's being brought up here?
19:12:21 <wumpus> IIRC monero-dev has a mirroring-bot as well and it works there
19:12:27 <luke-jr> IRC is easy
19:12:34 <sipa> provoostenator: ?
19:12:35 <achow101> I don't think it's hard to setup a mirroring bot at all
19:12:49 <provoostenator> IRC is a pain to setup because of the need for a bouncer
19:12:56 <testweb-morcos> so easy, can't we just tell people how to do this
19:13:19 <sipa> https://github.com/finnp/gitter-irc-bot
19:13:20 <wumpus> so - anyhow, if you want to try setting up a mirroring bot, seems people are ok with it
19:13:21 <achow101> provoostenator: IMO, no. we have a public log of this channel, so if someone isn't online, they can read that
19:13:22 <luke-jr> provoostenator: if someone wants a bouncer (it's not needed), point them at Quassel
19:13:22 <provoostenator> So it probably keeps at least some new devs from reaching out.
19:13:34 <wumpus> luke-jr: +1 for quassel
19:14:04 <achow101> also, there's already a "bitcoin core community" slack that we can use instead of setting up some new service
19:14:05 <Randolf> There are many different IRC clients available (including some web-based clients).  The problem with a lot of these proprietary messengers is that the options for client software is limited.
19:14:09 <wumpus> though if someone can't get IRC to work, I'm not sure how much of a dev they really are
19:14:11 <morcos> webchat.freenode.net is trivial for non-tech people, we should just have simple instructions for using that in some obviouse locations
19:14:23 <luke-jr> achow101: I hope that gets shut down in a month
19:15:05 <jimpo> +1 webchat.freenode.net
19:15:17 <luke-jr> morcos: +1
19:15:22 <dongcarl> Does webchat.freenode.net work for unregistered?
19:15:29 <luke-jr> dongcarl: yes
19:15:29 <Randolf> dongcarl:  Yes.
19:15:30 <provoostenator> I'm fine with better instructions for IRC too, especially if a Gitter bridge is too painful to setup. Agree that monitoring multiple chat things is not a good idea.
19:15:53 <luke-jr> achow101: (Slack is removing IRC support)
19:16:01 <achow101> luke-jr: they are??!!
19:16:06 <achow101> well that sucks
19:16:08 <luke-jr> yep
19:16:10 <cfields> yep
19:16:12 <provoostenator> Not a fan of Slack and it's closed nature.
19:16:14 <sipa> slack had IRC support?
19:16:21 * Randolf laughs
19:16:23 <dongcarl> and removing XMPP
19:16:25 <MarcoFalke> instructions are basically google for "webchat irc"
19:16:32 <BlueMatt> slack is garbage
19:16:33 <luke-jr> sipa: yes, until next month, you can login to slacks with an IRC client
19:16:37 <wumpus> slack is terrible, how can a chat client use so much resources
19:16:39 <cfields> sipa: yea, they had a bridge you could enable. Only reason I idle on a few slack channels.
19:16:58 <sipa> but the fact that that bitcoin core slack exists, and has people discussing things there who are not here, is probably a sign that there exists an actual barrier
19:16:59 <achow101> we can add a link in the readme that points to webchat.freenode
19:16:59 <Randolf> wumpus:  Discord uses a lot of resources too.  I tried it for a while but stopped.
19:17:04 <luke-jr> that's why I was on the Core slack at all
19:17:14 <provoostenator> wumpus: that's just Electron JS stuff taking up lots of memory.
19:17:20 <wumpus> achow101: FWIW the reason we haven't done that is to avoid people going here for suport questions
19:17:21 <luke-jr> sipa: I think the barrier is mobile software
19:17:28 <sipa> luke-jr: perhaps
19:17:39 <dongcarl> slack-to-IRC mirror?
19:17:56 <sipa> i've heard several smart people complain about IRC being hard to use, though
19:17:57 <wumpus> a bit of a a barrier isn't a bad thing, this channel is really only for development, not 'core discussion'
19:18:00 <achow101> maybe we should start pointing people to https://bitcoincore.org/en/contribute/
19:18:02 <jimpo> wumpus: In the contributing guide though?
19:18:05 <achow101> it has all the links and instructions
19:18:11 <luke-jr> sipa: ask for details? ☺
19:18:19 <jimpo> Putting instructions for webchat.freenode and the IRC logs?
19:18:28 <jimpo> Link to the logs is almost more valuable
19:18:31 <BlueMatt> sipa: we need to kill the fucking slack
19:18:35 <Randolf> sipa:  Many smart people have trouble using computers in general.  Oh well.
19:18:40 <sipa> BlueMatt: yes, i agree
19:18:44 <BlueMatt> or at least rename it Bitcoin Community, not Bitcoin Core....
19:18:59 <sipa> BlueMatt: but the fact that it exists is probably a sign that things can be improved
19:19:11 <wumpus> ok, time for next topic I think
19:19:14 <sipa> :)
19:19:39 <luke-jr> jonasschnelli: are you here today?
19:19:40 <wumpus> #topic what's up with #12694 and next steps? (sipa)
19:19:42 <gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
19:19:54 <sipa> achow101: what is the issue right now?
19:19:57 <achow101> 12694 is a bug fix because I forgot a line of code
19:20:03 <achow101> it got lost in a rebase somewhere
19:20:09 <sipa> then we should just merge it
19:20:11 <achow101> next steps are #12605
19:20:11 <sipa> how bad is it?
19:20:12 <gribble> https://github.com/bitcoin/bitcoin/issues/12605 | High level road map for coin selection changes · Issue #12605 · bitcoin/bitcoin · GitHub
19:20:38 <achow101> it gets messed up when people use preset inputs, but not too bad I think
19:20:49 <sipa> can you define "messed up" ?
19:20:53 <achow101> I think BnB will be missed when that happens, but there's no guarantee
19:21:05 <sipa> i see
19:21:30 <achow101> the preset inputs use actual value, but BnB uses effective value. So using both simultaneously can result in some strange behavior, particularly with fees
19:21:43 <sipa> what do you think about fixing BnB to work correctly with preset inputs (before also swapping out the fallback selection?)
19:21:59 <wumpus> yes seems #12694 is ready for merge
19:22:01 <gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
19:22:07 <sipa> as i expect that swapping out the fallback selections may take some time
19:22:09 <achow101> it requires switching everything over to use effective value
19:22:18 <sipa> hmm
19:22:33 <sipa> which is something you'd do anyway for the new fallback strategy anyway?
19:22:36 <achow101> yes
19:22:38 <sipa> gotcha
19:23:05 <achow101> I started working on using random selection as a fallback here: https://github.com/achow101/bitcoin/tree/srd-fallback
19:24:01 <sipa> ok
19:24:06 <wumpus> nice
19:24:08 <sipa> thanks, that clarified things
19:24:45 <wumpus> ok, any other topics?
19:24:51 <morcos> one sec
19:25:06 <meshcollider> EOL date for 0.13 ( https://github.com/bitcoin-core/bitcoincore.org/pull/528 )
19:25:06 <morcos> We have to as a project get on the same page for at least near term priorities on coin selection
19:25:35 <morcos> how do we weight privacy vs fee cost vs utxo set effects in aggregate
19:26:01 <luke-jr> users should get a choice per-tx ideally
19:26:02 <sipa> how do you even measure privacy?
19:26:05 <wumpus> #topic coin selection priorities
19:26:17 <morcos> previously we had said we can't worsen the overall utxo set effects, but this is a tough bar to meet given how "dumb" existing coin selection is
19:26:19 <sipa> without metric, there isn't even something to optimize for, even if we knew what we wanted
19:26:58 <wumpus> if possible we'd not want to reduce privacy at all
19:27:05 <luke-jr> sipa: ideally coinjoin everything with other users sending bitcoins at the same time. :p
19:27:11 <it-3276294625> I can write an bitcoin bruteforce generator
19:27:27 <morcos> well the question is, is it ok to make the coin selction consoldiate inputs less by default?  in exchange for perhaps increasing privacy and saving on fees?
19:27:38 <wumpus> luke-jr: he's talking about short-term
19:28:10 <morcos> my view, is that we shouldn't expect any wallet to do anything that is better for the local user, so if there is an aggregate net negative effect on the utxo
19:28:22 <luke-jr> morcos: depends on where you're sending them
19:28:27 <morcos> then that needs to be addressed with consensus costing changes in the long run (such as segwit)
19:28:43 <morcos> and we should give up trying to be overally globally nice at the expense of our own users in core
19:28:57 <morcos> for instance we currently spend non-economic inputs
19:29:02 <meshcollider> morcos: by consolidate less, you mean the total number would remain roughly the same? Or actively worsen
19:29:08 <luke-jr> consensus changes aren't that simple nor obvious
19:29:54 <morcos> meshcollider: i don't know... i don't trust the simulations that much, but it would be obvious from the algorithm that the utxo set growth by core wallets would be increased somewhat
19:29:59 <luke-jr> demurrage would probably make sense, but that would be so controversial it would never happen
19:30:19 <morcos> luke-jr: agreed, and we don't know now what the long term bottlenecks really are, so we couldn't even design the right answer , let alone implement it
19:30:34 <it-3276294625> How bitcoin keygen is build , between what parameters
19:30:47 <sipa> it-3276294625: not now; we're in a meeting
19:30:55 <it-3276294625> Ok
19:31:29 <wumpus> bitcoinwarezkeygencracker
19:31:44 * Randolf laughs
19:31:50 * luke-jr would not be surprised if that was a thing.
19:31:54 <wumpus> #topic EOL date for 0.13 (meshcollider)
19:31:55 <morcos> if murchandamus were here, i think he'd say that of course nothing is going to be as good for the utxo set as the existing core algo.   my argument is therefore we should allow ourself to make it worse, since thats not what anyone would design from scratch
19:32:26 <it-3276294625> wumpus: steel not answering to my question :)) what are the parameters that the code is generated
19:32:34 <wumpus> it-3276294625: go away
19:32:49 <meshcollider> morcos: yeah I think most users are more concerned with the fees, they can consolidate inputs themselves when fees are low
19:32:53 <wumpus> morcos: sorry! thought the topic was over
19:33:01 <morcos> no problem
19:33:28 <meshcollider> But consolidation worsens the coin selection performance does it?
19:33:29 <morcos> meshcollider: yeah and i'm in favor building iin functionality to do that in core too...  we should try to make it easy to be a good utxo citizen
19:33:32 <jcorgan> a rigorous definition of "loss of privacy" would go a long way toward being able to measure it
19:33:40 <morcos> meshcollider: what do you mean by performance?
19:33:50 <achow101> morcos: less utxo's make BnB less effective
19:34:18 <meshcollider> How well it can select inputs, a larger variety of inputs improves the selection doesn't it?
19:34:20 <morcos> achow101: well, we disagree on how much difference BnB makes.  i think exact matches are rare enough that trying to improve their frequency is a neglible effect
19:34:45 <sipa> morcos: in high-fee times i think they matter a lot, no?
19:34:52 <morcos> exact matches?
19:35:40 <sipa> within a window of the cost of creating change, yes
19:36:09 <morcos> i think they are still rare, but unforutnately neither of us have any data, b/c we dont know what core txs are from big wallets and what are from small
19:36:18 <sipa> fair
19:36:47 <morcos> but sure, i mean all you are arguing is maybe loosening consolidation isn't making things as bad as i'm saying
19:36:50 <morcos> great
19:37:32 <morcos> it sounds like we're mostly in agreement we can move in this direction, just not #reckless ly
19:37:43 <luke-jr> maybe we could have an opt-in statistics report at some point? just with the "exact match found? y/n" and vague wallet classifications?
19:37:58 <Randolf> luke-jr:  That's an interesting idea.
19:38:11 <meshcollider> "Bitcoin core would like to collect and share anonymous usage data with the developers"
19:38:14 <morcos> luke-jr: i certainly think that would be useful, but who would trust that
19:38:14 <luke-jr> delayed randomly to prevent fingerprinting
19:38:14 <meshcollider> Heh
19:38:33 <luke-jr> morcos: design it so the data can be public without revealing anything dangerous
19:38:35 <morcos> and next thing you know we're being subpoenaed for it
19:38:40 <morcos> perhaps
19:38:44 <Randolf> morcos:  I think a lot of users probably would use that feature.  I would because I'd see it as a way to support the future development of Bitcoin.
19:38:58 <achow101> luke-jr: make it so public that everything is publicly logged
19:39:13 <meshcollider> It'd be cool if it just wrote to a data file in the directory so they could just upload that file if they want to help
19:39:14 <morcos> yeah taht would be the only way
19:39:14 <luke-jr> achow101: yeah, we could literally have a site with all data received
19:39:39 <sipa> i'd be against that
19:40:00 <luke-jr> which part?
19:40:12 <sipa> having a single site that collecta data
19:40:15 <wumpus> would definitely be against automatic uploading
19:40:21 <Randolf> meshcollider:  I don't like that -- people should be asked first.  The problem is that spyware could copy such a file.
19:40:23 <cfields> if nothing else, seems the data would be skewed against the privacy metric anyway?
19:40:38 <sipa> cfields: right
19:40:54 <jcorgan> some ideas are just better left unexplored
19:41:36 <meshcollider> Ok are we moving to next topic now?
19:42:04 <Randolf> sipa:  Decentralized would certainly be better.
19:42:14 <meshcollider> Just a quick one, to discuss the EOL date for 0.13 since the lifecycle page on bitcoincore.org needs an update
19:42:25 <meshcollider> https://github.com/bitcoin-core/bitcoincore.org/pull/528
19:42:28 <morcos> ready to move on
19:42:39 <Randolf> meshcollider:  I think the date suggested there is reasonable.
19:42:41 <luke-jr> I still use 0.13 for my cold wallet, but I'm not willing to commit to maintaining it
19:43:20 <MarcoFalke> It is already unmaintained
19:43:52 <wumpus> meshcollider: looks good to me
19:44:16 <meshcollider> Sweet, jnewbery just wanted to have it discussed here
19:44:19 <luke-jr> MarcoFalke: then it shouldbe a past date
19:44:31 <meshcollider> luke-jr: there are 2 dates
19:44:35 <MarcoFalke> ^
19:44:45 <meshcollider> One is end of maintenance, the other is full EOL
19:44:46 <luke-jr> I know
19:45:16 <meshcollider> Ok that's that then. Any other topics?
19:45:32 <wumpus> right, maintenance means that there could be general bugfix releases on that branch, EOL means even cricitcal security patches won't be backported to that
19:46:06 <luke-jr> which is what I was referring to anyway
19:46:15 <achow101> i think luke-jr is saying that 0.13 is already past EOL
19:46:24 <jnewbery> date seems fine to me. Is there any convention we use to set the EOL date?
19:46:38 <Randolf> achow101:  Then perhaps the EOL date should be changed to today?
19:46:54 <wumpus> +/- a year after end maintenance
19:47:16 <meshcollider> Note that 0.12 EOL was only 3 weeks ago
19:47:25 <luke-jr> achow101: well, that depends on the rest of you all; if someone will backport critical fixes..
19:47:55 <luke-jr> I just meant that I'm not willing to commit to doing it longer ☺
19:49:08 <wumpus> me neither
19:49:13 <wumpus> any other topics?
19:49:58 <achow101> luke-jr: I doubt there will be anything that requires another 0.13 release in the next 4 months anyways
19:50:57 <MarcoFalke> https://github.com/bitcoin/bitcoin/blame/f686002a8eba820a40ac2f34a6e8f57b2b5cc54c/doc/release-process.md#L297 could be modified to include "Update https://github.com/bitcoin-core/bitcoincore.org/blob/master/_includes/posts/_maintenance-table.md"
19:51:23 <achow101> while we're talking about this, maybe we should also set 0.14's EOL date
19:52:17 <meshcollider> Feb 1 2019?
19:52:49 <jnewbery> meshcollider: +1
19:52:54 <Randolf> achow101:  This starts to venture into another question:  How many previous versions should be supported/non-EOL?
19:53:02 <Randolf> Should there be a maximum number?
19:53:44 <jcorgan> said number would be dynamic an depend entirely on the willingness of volunteers to do it
19:53:47 <achow101> Randolf: IIRC we always did current, previous as maintenance, and one before that critical updates only
19:54:00 <luke-jr> Randolf: all depends on what developers are willing to maintain
19:54:20 <luke-jr> several years ago, I maintained some versions for years
19:55:01 <wumpus> also depends on the scope of the problem, if it's a simple backport, it's easy to roll another 0.13 version anyway, if it takes a full-on refactor first, no one will likely bother
19:55:03 <jcorgan> if there were an user/organization that was dependent upon security and/or bug fixes in an older, unmaintained version, they could certainly pay industry rates to a competent person to do so
19:55:13 <luke-jr> jcorgan: +1
19:55:30 <Randolf> luke-jr++
19:56:12 <sipa> (luke) - (jr++) ?
19:56:14 <Randolf> wumpus:  I can see that if it's a major job, the recommendation will be to upgrade to a newer version anyway.
19:56:26 <wumpus> Randolf: yes
19:56:26 <luke-jr> sipa: lol
19:57:01 <jcorgan> the issue would come up with someone who maintains and uses a modified branch
19:57:31 <jcorgan> it might be easier to pay someone to backport something than to try to roll their changes forward
19:57:48 <luke-jr> depends on what it is
19:57:58 <jcorgan> sure
19:58:12 <Randolf> sipa:  I'm used to the karma bot in the #perl channel.  :)
19:58:22 <achow101> on a semi-related note, should we remove the branches for EOL versions
19:58:31 <bitcoin-git> [13bitcoin] 15jimpo opened pull request #12760: Docs: Improve documentation on standard communication channels. (06master...06communication-channels) 02https://github.com/bitcoin/bitcoin/pull/12760
19:58:42 <wumpus> achow101: probably
19:59:43 <wumpus> has been a while since I last cleaned up branches
20:00:01 <sipa> PLOINK
20:00:09 <wumpus> #endmeeting