< bitcoin-git> [bitcoin] eklitzke closed pull request #12649: Add documentation about generating flame graphs. (master...flamegraphs) https://github.com/bitcoin/bitcoin/pull/12649
< bitcoin-git> [bitcoin] Empact closed pull request #12745: Expose node relay fee settings in help, independent of -help-debug (master...expose-relay-fee-settings-help) https://github.com/bitcoin/bitcoin/pull/12745
< koichirose> hello! what could be the reason for 0.16 to always return legacy addresses, even with 'getnewaddress “” p2sh-segwit’?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e0f7515f5500...ad823178e85a
< bitcoin-git> bitcoin/master bcab47b Kevin Pan: use base58 map instead of strchr()
< bitcoin-git> bitcoin/master ad82317 Wladimir J. van der Laan: Merge #12704: base58: use map instead of strchr() when decode...
< bitcoin-git> [bitcoin] laanwj closed pull request #12704: base58: use map instead of strchr() when decode (master...b58_bitmap) https://github.com/bitcoin/bitcoin/pull/12704
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad823178e85a...185d48473e43
< bitcoin-git> bitcoin/master 0ec08a6 John Newbery: [Tests] Move assert_start_raises_init_error method to TestNode
< bitcoin-git> bitcoin/master 5812273 John Newbery: [Tests] Require exact match in assert_start_raises_init_eror()
< bitcoin-git> bitcoin/master fae1374 MarcoFalke: qa: Allow for partial_match when checking init error...
< bitcoin-git> [bitcoin] laanwj closed pull request #12718: [Tests] Require exact match in assert_start_raises_init_eror (jnewbery) (master...Mf1803-qaRegexInitError) https://github.com/bitcoin/bitcoin/pull/12718
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/185d48473e43...6d36f599f88e
< bitcoin-git> bitcoin/master c8330d4 MarcoFalke: qa: Use node.datadir instead of tmpdir in test framework
< bitcoin-git> bitcoin/master 6d36f59 Wladimir J. van der Laan: Merge #12076: qa: Use node.datadir instead of tmpdir in test framework...
< bitcoin-git> [bitcoin] laanwj closed pull request #12076: qa: Use node.datadir instead of tmpdir in test framework (master...Mf1801-qaUseUtilDatadir) https://github.com/bitcoin/bitcoin/pull/12076
< wumpus> jnewbery: done
< timothy> is it normal that verificationprogress in getblockchaininfo are never 1?
< timothy> when blockchain in synched too
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6d36f599f88e...a6926b065d65
< bitcoin-git> bitcoin/master 1e0ee90 Martin Ankerl: Use best-fit strategy in Arena, now O(log(n)) instead O(n)...
< bitcoin-git> bitcoin/master 5fbf7c4 Martin Ankerl: fix nits: variable naming, typos
< bitcoin-git> bitcoin/master a6926b0 Wladimir J. van der Laan: Merge #12048: Use best-fit strategy in Arena, now O(log(n)) instead O(n)...
< bitcoin-git> [bitcoin] laanwj closed pull request #12048: Use best-fit strategy in Arena, now O(log(n)) instead O(n) (master...faster_arena) https://github.com/bitcoin/bitcoin/pull/12048
< eklitzke> timothy: it's normal, it uses a heuristic to guess what the current tip is as a floating point height
< timothy> eklitzke: so it's better to use something like bitcoin-cli getblockchaininfo | jq ".blocks == .headers" ?
< timothy> to know when it's synched
< eklitzke> i just check if progress is > 0.9999 but that seems reasonable to me too
< echeveria> probably no reason to not expose isInitalBlockDownload there.
< bitcoin-git> [bitcoin] jnewbery opened pull request #12755: [tests] Better stderr testing (master...better_stderr_testing) https://github.com/bitcoin/bitcoin/pull/12755
< bitcoin-git> [bitcoin] jnewbery closed pull request #12379: [WIP] Better stderr testing in functional tests (master...test_full_stderr2) https://github.com/bitcoin/bitcoin/pull/12379
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a6926b065d65...c290508a5ebf
< bitcoin-git> bitcoin/master 8674e74 murrayn: Provide relevant error message if datadir is not writable.
< bitcoin-git> bitcoin/master c290508 Wladimir J. van der Laan: Merge #12630: Provide useful error message if datadir is not writable....
< bitcoin-git> [bitcoin] laanwj closed pull request #12630: Provide useful error message if datadir is not writable. (master...datadir_writable) https://github.com/bitcoin/bitcoin/pull/12630
< bitcoin-git> [bitcoin] jnewbery opened pull request #12756: [config] Remove blockmaxsize option (master...remove_blockmaxsize) https://github.com/bitcoin/bitcoin/pull/12756
< instagibbs> wumpus, #12742 looks ready
< gribble> https://github.com/bitcoin/bitcoin/issues/12742 | Make FastRandomContext support standard C++11 RNG interface by sipa · Pull Request #12742 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] practicalswift opened pull request #12757: Clarify include guard naming convention (master...include-guard) https://github.com/bitcoin/bitcoin/pull/12757
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c290508a5ebf...f686002a8eba
< bitcoin-git> bitcoin/master 1ec1602 Pieter Wuille: Make FastRandomContext support standard C++11 RNG interface...
< bitcoin-git> bitcoin/master f686002 MarcoFalke: Merge #12742: Make FastRandomContext support standard C++11 RNG interface...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12742: Make FastRandomContext support standard C++11 RNG interface (master...201803_stdrandom) https://github.com/bitcoin/bitcoin/pull/12742
< bitcoin-git> [bitcoin] eklitzke opened pull request #12759: [Docs] Improve formatting of developer notes (master...developer-notes) https://github.com/bitcoin/bitcoin/pull/12759
< Randolf> I was looking at the FAQ at the Bitcoin.org web site, and I didn't find any mention of Segregated Witness nor the Lightning Network. I'm wondering if an entry should be added? https://bitcoin.org/en/faq#transactions
< Randolf> The reason I ask about this is that I've seen questions in the #bitcoin channel and in other forums about this, and it seems that there is confusion regarding it.
< sipa> Randolf: i'm sure they value contributions
< Randolf> sipa: Is bitcoin.org's content not part of overall project?
< BlueMatt> I believe bitcoin.org has gone mostly unmaintained for the past few months, so segwit stuff never landed before folks stopped working
< Randolf> A few months is not a big deal to me. I'd be happy to write something up for the FAQ.
< sipa> Randolf: no, it's a site privately run website
< Randolf> I just need to know a bit more about the Lightning Network support before I do that.
< sipa> Randolf: the project's website is bitcoincore.org
< Randolf> sipa: I know that Bitcoin.com is privately owned and operated by a BCash fanatic. I was always under the impression that Bitcoin.org was the good one.
< Randolf> Yeah, I know that BitcoinCore.org is part of the development side of things.
< BlueMatt> no, bitcoin.org is *also* a privately-run website
< BlueMatt> I mean it doesnt deliberately try to confuse people as to the bcash-v-bitcoin thing, so its better in that regard, sure
< BlueMatt> but similar setup
< BlueMatt> bitcoincore.org is the *only* site that is in any way associated with the bitcoin core project
< Randolf> According to WHOIS, bitcoin.org is legally owned by "WhoisGuard, Inc."
< wumpus> last I heard cobra was busy with a redesign of bitcoin.org, but yea maintenance for the site is not very active in general. That shouldn't dissuade you from contributing, though.
< Randolf> wumpus: I don't typically judge web sites by their update frequency.
< Randolf> While it makes sense for some web sites (e.g., news), for most just having high quality content is sufficient.
< wumpus> doesn't seem there is a PR open yet adding informatino about segwit or lightning: https://github.com/bitcoin-dot-org/bitcoin.org/pulls
< Randolf> wumpus: Thanks for that link. I'll try to get involved in that project.
< wumpus> thanks
< dongcarl> Does anyone understand dwheeler's DDC method? Could be good for further ensuring binary security when integrated with Gitian.
< wumpus> I don't know about it - but probably better to ask that after the meeting
< sipa> meeting!
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Mar 22 19:00:45 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< provoostenator> Hi
< morcos> kind of here
< 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
< kanzure> hi.
< cfields> hi
< achow101> oh right, it's thursday
< wumpus> yep
< instagibbs> hi
< wumpus> any topic suggestions?
< BlueMatt> <topic suggestion>
< wumpus> #topic high priority for review
< ryanofsky> #11536
< gribble> https://github.com/bitcoin/bitcoin/issues/11536 | Rename account to label where appropriate by ryanofsky · Pull Request #11536 · bitcoin/bitcoin · GitHub
< meshcollider> Hi
< Randolf> Hello.
< wumpus> ryanofsky: anothing specific you want to discuss regarding that pr?
< ryanofsky> just curious about status, if it is ready to be merged or if it needs more review
< wumpus> anything that needs to be added/removed from high priority for review?
< wumpus> ryanofsky: makes sense
< sipa> i'll have a look in a minute
< Randolf> PR #12759 looks like it would be an easy one to merge quickly.
< gribble> https://github.com/bitcoin/bitcoin/issues/12759 | [Docs] Improve formatting of developer notes by eklitzke · Pull Request #12759 · bitcoin/bitcoin · GitHub
< wumpus> Randolf: that's not the topic though
< Randolf> Oh, sorry.
< wumpus> formatting of developer notes is not 'high priority for review' in any definition
< Randolf> I though you were asking if there was anything to add/remove for review.
< Randolf> I see. Yes.
< wumpus> high priority for review description is: These either block other important work in progress, or are necessary for backport to a minor release.
< Randolf> Thank you.
< wumpus> if something can be merged it's better to let me know outside the meeting
< wumpus> anyhow, it seems people are happy with the current set, next topic
< provoostenator> Topic suggestion: Gitter (we talked about this recently as a way to lower barrier for new contributors, compared to IRC)
< jimpo> I've already got one in high pri for review list, but #11857 is more of a blocker for my work
< gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
< sipa> jimpo: agree that seems a better candidate for now
< wumpus> jimpo: swap it out?
< jimpo> Yep
< sipa> can i have #12714 on the list?
< gribble> https://github.com/bitcoin/bitcoin/issues/12714 | Introduce interface for signing providers by sipa · Pull Request #12714 · bitcoin/bitcoin · GitHub
< wumpus> jimpo: done
< wumpus> sipa: done
< wumpus> #topic Rename account to label where appropriate (ryanofsky)
< provoostenator> That PR seems more or less ready to go, right?
< wumpus> <ryanofsky> just curious about status, if it is ready to be merged or if it needs more review
< meshcollider> It has 3 tested acks and a utACK already, looks very close if not ready
< wumpus> ok!
< achow101> I thought that was supposed to go after #7729?
< gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
< ryanofsky> yeah, i think it's ready
< achow101> or did I get the order backwards
< meshcollider> Yeah other way around achow101
< wumpus> if it's ready it should go in
< sipa> achow101: 12714 is just a first step taken out of 7729
< achow101> oh, ok
< sipa> topic suggestion: what's up with #12694 and next steps?
< gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
< meshcollider> Topic suggestion: EOL date for 0.13 ( https://github.com/bitcoin-core/bitcoincore.org/pull/528 )
< wumpus> #topic gitter (provoostenator)
< BlueMatt> it'd have to be mirrored to irc
< sipa> gitter has an IRC interface
< BlueMatt> bidirectionally, that is
< sipa> as in, you can connect to it as an IRC server
< BlueMatt> sipa: that requires we all move our bouncers, I think thats more than its worth
< wumpus> I've never used gitter, but I'm not going to join any more chat services
< sipa> well what's the context?
< luke-jr> what is it?
< sipa> i don't think we're planning to move this channel...
< BlueMatt> its my impression it can be bidirectionally mirrored to irc, which would be fine, but I'm not sure how much its worth
< Randolf> I've tried other chat services, and they're just not as good as IRC.
< BlueMatt> sipa: its some newfangled slack-like bullshit that is "for open source projects"
< wumpus> mirroring sounds fine to me, if ti doesn't increase the noise level too much
< sipa> BlueMatt: i know; i've used it for another project before and it works pretty well
< achow101> Isn't the idea to make it easier for people to start contributing?
< sipa> but i'm wondering why it's being brought up here?
< wumpus> IIRC monero-dev has a mirroring-bot as well and it works there
< luke-jr> IRC is easy
< sipa> provoostenator: ?
< achow101> I don't think it's hard to setup a mirroring bot at all
< provoostenator> IRC is a pain to setup because of the need for a bouncer
< testweb-morcos> so easy, can't we just tell people how to do this
< wumpus> so - anyhow, if you want to try setting up a mirroring bot, seems people are ok with it
< achow101> provoostenator: IMO, no. we have a public log of this channel, so if someone isn't online, they can read that
< luke-jr> provoostenator: if someone wants a bouncer (it's not needed), point them at Quassel
< provoostenator> So it probably keeps at least some new devs from reaching out.
< wumpus> luke-jr: +1 for quassel
< achow101> also, there's already a "bitcoin core community" slack that we can use instead of setting up some new service
< 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.
< wumpus> though if someone can't get IRC to work, I'm not sure how much of a dev they really are
< morcos> webchat.freenode.net is trivial for non-tech people, we should just have simple instructions for using that in some obviouse locations
< luke-jr> achow101: I hope that gets shut down in a month
< jimpo> +1 webchat.freenode.net
< luke-jr> morcos: +1
< dongcarl> Does webchat.freenode.net work for unregistered?
< luke-jr> dongcarl: yes
< Randolf> dongcarl: Yes.
< 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.
< luke-jr> achow101: (Slack is removing IRC support)
< achow101> luke-jr: they are??!!
< achow101> well that sucks
< luke-jr> yep
< cfields> yep
< provoostenator> Not a fan of Slack and it's closed nature.
< sipa> slack had IRC support?
< * Randolf> laughs
< dongcarl> and removing XMPP
< MarcoFalke> instructions are basically google for "webchat irc"
< BlueMatt> slack is garbage
< luke-jr> sipa: yes, until next month, you can login to slacks with an IRC client
< wumpus> slack is terrible, how can a chat client use so much resources
< cfields> sipa: yea, they had a bridge you could enable. Only reason I idle on a few slack channels.
< 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
< achow101> we can add a link in the readme that points to webchat.freenode
< Randolf> wumpus: Discord uses a lot of resources too. I tried it for a while but stopped.
< luke-jr> that's why I was on the Core slack at all
< provoostenator> wumpus: that's just Electron JS stuff taking up lots of memory.
< wumpus> achow101: FWIW the reason we haven't done that is to avoid people going here for suport questions
< luke-jr> sipa: I think the barrier is mobile software
< sipa> luke-jr: perhaps
< dongcarl> slack-to-IRC mirror?
< sipa> i've heard several smart people complain about IRC being hard to use, though
< wumpus> a bit of a a barrier isn't a bad thing, this channel is really only for development, not 'core discussion'
< achow101> maybe we should start pointing people to https://bitcoincore.org/en/contribute/
< jimpo> wumpus: In the contributing guide though?
< achow101> it has all the links and instructions
< luke-jr> sipa: ask for details? ☺
< jimpo> Putting instructions for webchat.freenode and the IRC logs?
< jimpo> Link to the logs is almost more valuable
< BlueMatt> sipa: we need to kill the fucking slack
< Randolf> sipa: Many smart people have trouble using computers in general. Oh well.
< sipa> BlueMatt: yes, i agree
< BlueMatt> or at least rename it Bitcoin Community, not Bitcoin Core....
< sipa> BlueMatt: but the fact that it exists is probably a sign that things can be improved
< wumpus> ok, time for next topic I think
< sipa> :)
< luke-jr> jonasschnelli: are you here today?
< wumpus> #topic what's up with #12694 and next steps? (sipa)
< gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
< sipa> achow101: what is the issue right now?
< achow101> 12694 is a bug fix because I forgot a line of code
< achow101> it got lost in a rebase somewhere
< sipa> then we should just merge it
< achow101> next steps are #12605
< sipa> how bad is it?
< gribble> https://github.com/bitcoin/bitcoin/issues/12605 | High level road map for coin selection changes · Issue #12605 · bitcoin/bitcoin · GitHub
< achow101> it gets messed up when people use preset inputs, but not too bad I think
< sipa> can you define "messed up" ?
< achow101> I think BnB will be missed when that happens, but there's no guarantee
< sipa> i see
< 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
< sipa> what do you think about fixing BnB to work correctly with preset inputs (before also swapping out the fallback selection?)
< wumpus> yes seems #12694 is ready for merge
< gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
< sipa> as i expect that swapping out the fallback selections may take some time
< achow101> it requires switching everything over to use effective value
< sipa> hmm
< sipa> which is something you'd do anyway for the new fallback strategy anyway?
< achow101> yes
< sipa> gotcha
< achow101> I started working on using random selection as a fallback here: https://github.com/achow101/bitcoin/tree/srd-fallback
< sipa> ok
< wumpus> nice
< sipa> thanks, that clarified things
< wumpus> ok, any other topics?
< morcos> one sec
< meshcollider> EOL date for 0.13 ( https://github.com/bitcoin-core/bitcoincore.org/pull/528 )
< morcos> We have to as a project get on the same page for at least near term priorities on coin selection
< morcos> how do we weight privacy vs fee cost vs utxo set effects in aggregate
< luke-jr> users should get a choice per-tx ideally
< sipa> how do you even measure privacy?
< wumpus> #topic coin selection priorities
< 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
< sipa> without metric, there isn't even something to optimize for, even if we knew what we wanted
< wumpus> if possible we'd not want to reduce privacy at all
< luke-jr> sipa: ideally coinjoin everything with other users sending bitcoins at the same time. :p
< it-3276294625> I can write an bitcoin bruteforce generator
< 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?
< wumpus> luke-jr: he's talking about short-term
< 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
< luke-jr> morcos: depends on where you're sending them
< morcos> then that needs to be addressed with consensus costing changes in the long run (such as segwit)
< morcos> and we should give up trying to be overally globally nice at the expense of our own users in core
< morcos> for instance we currently spend non-economic inputs
< meshcollider> morcos: by consolidate less, you mean the total number would remain roughly the same? Or actively worsen
< luke-jr> consensus changes aren't that simple nor obvious
< 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
< luke-jr> demurrage would probably make sense, but that would be so controversial it would never happen
< 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
< it-3276294625> How bitcoin keygen is build , between what parameters
< sipa> it-3276294625: not now; we're in a meeting
< it-3276294625> Ok
< wumpus> bitcoinwarezkeygencracker
< * Randolf> laughs
< * luke-jr> would not be surprised if that was a thing.
< wumpus> #topic EOL date for 0.13 (meshcollider)
< 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
< it-3276294625> wumpus: steel not answering to my question :)) what are the parameters that the code is generated
< wumpus> it-3276294625: go away
< meshcollider> morcos: yeah I think most users are more concerned with the fees, they can consolidate inputs themselves when fees are low
< wumpus> morcos: sorry! thought the topic was over
< morcos> no problem
< meshcollider> But consolidation worsens the coin selection performance does it?
< 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
< jcorgan> a rigorous definition of "loss of privacy" would go a long way toward being able to measure it
< morcos> meshcollider: what do you mean by performance?
< achow101> morcos: less utxo's make BnB less effective
< meshcollider> How well it can select inputs, a larger variety of inputs improves the selection doesn't it?
< 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
< sipa> morcos: in high-fee times i think they matter a lot, no?
< morcos> exact matches?
< sipa> within a window of the cost of creating change, yes
< 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
< sipa> fair
< morcos> but sure, i mean all you are arguing is maybe loosening consolidation isn't making things as bad as i'm saying
< morcos> great
< morcos> it sounds like we're mostly in agreement we can move in this direction, just not #reckless ly
< 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?
< Randolf> luke-jr: That's an interesting idea.
< meshcollider> "Bitcoin core would like to collect and share anonymous usage data with the developers"
< morcos> luke-jr: i certainly think that would be useful, but who would trust that
< luke-jr> delayed randomly to prevent fingerprinting
< meshcollider> Heh
< luke-jr> morcos: design it so the data can be public without revealing anything dangerous
< morcos> and next thing you know we're being subpoenaed for it
< morcos> perhaps
< 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.
< achow101> luke-jr: make it so public that everything is publicly logged
< 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
< morcos> yeah taht would be the only way
< luke-jr> achow101: yeah, we could literally have a site with all data received
< sipa> i'd be against that
< luke-jr> which part?
< sipa> having a single site that collecta data
< wumpus> would definitely be against automatic uploading
< Randolf> meshcollider: I don't like that -- people should be asked first. The problem is that spyware could copy such a file.
< cfields> if nothing else, seems the data would be skewed against the privacy metric anyway?
< sipa> cfields: right
< jcorgan> some ideas are just better left unexplored
< meshcollider> Ok are we moving to next topic now?
< Randolf> sipa: Decentralized would certainly be better.
< meshcollider> Just a quick one, to discuss the EOL date for 0.13 since the lifecycle page on bitcoincore.org needs an update
< morcos> ready to move on
< Randolf> meshcollider: I think the date suggested there is reasonable.
< luke-jr> I still use 0.13 for my cold wallet, but I'm not willing to commit to maintaining it
< MarcoFalke> It is already unmaintained
< wumpus> meshcollider: looks good to me
< meshcollider> Sweet, jnewbery just wanted to have it discussed here
< luke-jr> MarcoFalke: then it shouldbe a past date
< meshcollider> luke-jr: there are 2 dates
< MarcoFalke> ^
< meshcollider> One is end of maintenance, the other is full EOL
< luke-jr> I know
< meshcollider> Ok that's that then. Any other topics?
< 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
< luke-jr> which is what I was referring to anyway
< achow101> i think luke-jr is saying that 0.13 is already past EOL
< jnewbery> date seems fine to me. Is there any convention we use to set the EOL date?
< Randolf> achow101: Then perhaps the EOL date should be changed to today?
< wumpus> +/- a year after end maintenance
< meshcollider> Note that 0.12 EOL was only 3 weeks ago
< luke-jr> achow101: well, that depends on the rest of you all; if someone will backport critical fixes..
< luke-jr> I just meant that I'm not willing to commit to doing it longer ☺
< wumpus> me neither
< wumpus> any other topics?
< achow101> luke-jr: I doubt there will be anything that requires another 0.13 release in the next 4 months anyways
< achow101> while we're talking about this, maybe we should also set 0.14's EOL date
< meshcollider> Feb 1 2019?
< jnewbery> meshcollider: +1
< Randolf> achow101: This starts to venture into another question: How many previous versions should be supported/non-EOL?
< Randolf> Should there be a maximum number?
< jcorgan> said number would be dynamic an depend entirely on the willingness of volunteers to do it
< achow101> Randolf: IIRC we always did current, previous as maintenance, and one before that critical updates only
< luke-jr> Randolf: all depends on what developers are willing to maintain
< luke-jr> several years ago, I maintained some versions for years
< 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
< 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
< luke-jr> jcorgan: +1
< Randolf> luke-jr++
< sipa> (luke) - (jr++) ?
< Randolf> wumpus: I can see that if it's a major job, the recommendation will be to upgrade to a newer version anyway.
< wumpus> Randolf: yes
< luke-jr> sipa: lol
< jcorgan> the issue would come up with someone who maintains and uses a modified branch
< jcorgan> it might be easier to pay someone to backport something than to try to roll their changes forward
< luke-jr> depends on what it is
< jcorgan> sure
< Randolf> sipa: I'm used to the karma bot in the #perl channel. :)
< achow101> on a semi-related note, should we remove the branches for EOL versions
< bitcoin-git> [bitcoin] jimpo opened pull request #12760: Docs: Improve documentation on standard communication channels. (master...communication-channels) https://github.com/bitcoin/bitcoin/pull/12760
< wumpus> achow101: probably
< wumpus> has been a while since I last cleaned up branches
< sipa> PLOINK
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Mar 22 20:00:09 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< luke-jr> sipa lays down the time limit
< luke-jr> heading home, this worked out well; bbl
< Randolf> Take care luke-jr.
< Randolf> Good day to everyone. That seemed to be a very productive meeting.
< wumpus> later
< achow101> wumpus: merge #12694
< gribble> https://github.com/bitcoin/bitcoin/issues/12694 | Actually disable BnB when there are preset inputs by achow101 · Pull Request #12694 · bitcoin/bitcoin · GitHub
< achow101> ?
< wumpus> yes
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f686002a8eba...9552dfb1f632
< bitcoin-git> bitcoin/master 6ef9982 Andrew Chow: Actually disable BnB when there are preset inputs...
< bitcoin-git> bitcoin/master 081bf54 Andrew Chow: Test that BnB is not used when there are preset inputs
< bitcoin-git> bitcoin/master 9552dfb Wladimir J. van der Laan: Merge #12694: Actually disable BnB when there are preset inputs...
< bitcoin-git> [bitcoin] laanwj closed pull request #12694: Actually disable BnB when there are preset inputs (master...fix-preset-coins-bnb) https://github.com/bitcoin/bitcoin/pull/12694
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9552dfb1f632...cead84b72d27
< bitcoin-git> bitcoin/master 045eeb8 Russell Yanofsky: Rename account to label where appropriate...
< bitcoin-git> bitcoin/master d2527bd Russell Yanofsky: Rename wallet_accounts.py test...
< bitcoin-git> bitcoin/master cead84b Wladimir J. van der Laan: Merge #11536: Rename account to label where appropriate...
< bitcoin-git> [bitcoin] laanwj closed pull request #11536: Rename account to label where appropriate (master...pr/acct) https://github.com/bitcoin/bitcoin/pull/11536
< justin__> any reason not to further lower relay fee even 1 sat/byte seems expensive nowadays or am I just cheap? :P
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12757: Clarify include guard naming convention (master...include-guard) https://github.com/bitcoin/bitcoin/pull/12757
< luke-jr> justin__: any lower probably won't get relayed, but off-topic here.