< 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?
< 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
< 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>
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
< 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>
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?)
< 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
< 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)