< luke-jr>
sometimes I wish software had an increment-only security-fix counter common across the rest of the version :x
< luke-jr>
so one could know so long as the Nth digit is latest, it has all known security issues patched
< echeveria>
luke-jr: that doesn't really work so well where patches needed total rewrites, ie the utxo
< luke-jr>
sure it does? if 99 has a bug, anything unaffected must be >=100
< luke-jr>
then the advisory can just say "be sure you have version >= x.y.100
< kallewoof>
that's a nice idea, but if version 2.1.3.99 has a vulnerability that none of the other versions have, then 2.1.2.99 is not affected even though its security counter < 100
< kallewoof>
unless the authors just bump the version without changing anything every time security counter is bumped up, even for unaffected versions.
< kallewoof>
s/bump the version/release same v with counter updated/
< luke-jr>
kallewoof: yeah, but if that's the worst case scenario, it's still an improvement
< luke-jr>
and using 2.1.3.100 instead of 2.1.2.99 is less of a problem with this, than if 2.1.3.100 might be vulnerable, but 2.1.2.99 isn't.
< * kallewoof>
nods
< bitcoin-git>
[bitcoin] ariard opened pull request #15842: refactor: replace isPotentialtip/waitForNotifications by higher method (master...2019-04-is-potential-tip) https://github.com/bitcoin/bitcoin/pull/15842
< bitcoin-git>
bitcoin/0.18 5546207 Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
< bitcoin-git>
bitcoin/0.18 a58d80d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
< bitcoin-git>
[bitcoin] laanwj merged pull request #15801: Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit (master...bugfix_gui_prune_range) https://github.com/bitcoin/bitcoin/pull/15801
< MarcoFalke>
john has force pushed #15778, and the branch is no longer corrupted. Though, something to keep in mind when blindly fetching from GitHub.
< moneyball>
i have a brief topic i'd like to cover after we go through other topics - an opportunity to meet with the github CEO and share feedback from this project
< jnewbery>
gwillen asked for #15024 to go in after the last wallet meeting
< jonasschnelli>
We could also add a project column per non-author-proposer
< jonasschnelli>
I don't expect we would have a lot
< wumpus>
moneyball: thanks
< wumpus>
#topic Should send-to-non-v0-witness be standard (sipa)
< sipa>
hi
< sipa>
so we currently have two policy rules w.r.t. future segwit versions
< sipa>
one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard
< wumpus>
jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards'
< sipa>
the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard
< sipa>
i believe that first rule does more harm than good
< gmaxwell>
The tradeoff is: if you make payments to bech32 addresses with 'future' segwit versions, should your payment get stuck (esp ugly for a send many or if your wallet has few inputs) OR should users be somewhat more exposed to stupidly sending to an insecure 'future' address.
< meshcollider>
I'm inclined to agree
< gmaxwell>
I agree the first rule does more harm than good.
< sipa>
i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late
< sipa>
so if we want that rule, i believe it belongs in the wallet, not in relay policy
< MarcoFalke>
No wallet should create thos addresses
< luke-jr>
(getting stuck is a problem because it locks up your change)
< gmaxwell>
To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets.
< sdaftuar>
sipa: are you suggesting it should be wallet rule to not send to those addresses?
< sipa>
sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet
< gmaxwell>
ugh.
< sdaftuar>
sipa: i think i can agree that it should not be a relay policy, but i'm skeptical of making it a wallet rule
< jnewbery>
Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction
< wumpus>
I tend to agree, this selfs a self-sabotaging relay policy
< sipa>
sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :)
< jnewbery>
I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay
< luke-jr>
tangent: if relay policy allows it, maybe it should always allow RBF on it?
< sipa>
jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best
< sdaftuar>
jnewbery: if wallet doesn't send to such addresses, we will have a similar problem rolling out v1 segwit addresses as rolling out bech32
< gmaxwell>
jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity.
< luke-jr>
jnewbery: but isn't the whole point of Bech32's extensibility in this regard, so that we don't need to upgrade wallets to send to new versions?
< sipa>
luke-jr: yup
< wumpus>
forward compatibility is kind of useful
< meshcollider>
Exactly...
< gmaxwell>
and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address.
< sipa>
yeah, i think my preference is not having the rule in the first place
< luke-jr>
IMO allow relay and wallet, but force RBF opt-in ;)
< jnewbery>
delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15
< wumpus>
there's *tons* of ways to send coins into the void, I don't think doing this accidentally is anything more likely than sending to a non-existant classic address for ex.
< meshcollider>
So I also dont think the wallet should refuse to send either, a warning at most
< jnewbery>
it's caused by other wallets and exchanges in the ecosystem
< gmaxwell>
We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
< luke-jr>
jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do
< sdaftuar>
luke-jr: +1
< jnewbery>
which is not send to non-v0 until there is a defined v1
< wumpus>
a warning would be okey
< achow101>
the fact that it's not a relay policy will lock up change
< gmaxwell>
We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves
< wumpus>
but I think we agree, this should not be relay policy
< sipa>
i'll PR removing it from relay policy
< wumpus>
relay policy has never been used to protect users, if so, why no excessive fee check?
< sipa>
wumpus: exactly
< gmaxwell>
wumpus: kinda one sec on that point.
< jonasschnelli>
indeed
< instagibbs>
sipa, it's worth a mailing list email?
< jnewbery>
I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1
< gmaxwell>
wumpus: There is a non-protection argument too... we generally tend to not relay forward compatiblity features, in order to protect their future usage.
< jonasschnelli>
instagibbs: seems to be Core policy,... no need for ML?!
< luke-jr>
jnewbery: but then we could just as well make a new address format for every version
< gmaxwell>
wumpus: but for _output types_ this doesn't apply.
< wumpus>
gmaxwell:right
< cfields>
replace-by-version? :p
< MarcoFalke>
jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated
< luke-jr>
jonasschnelli: it seems likely a topic other software would want to consider and act on too
< sipa>
actually
< instagibbs>
jonasschnelli, people may have made assumptions based on current policy, right or wrong?
< jnewbery>
luke-jr: that' not the same at all. This is a one-line (or config) or config
< gmaxwell>
jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets.
< sipa>
this is a violation of BIP173
< gmaxwell>
sipa: correct.
< sipa>
"Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. "
< jonasschnelli>
oh
< wumpus>
it makes sense to inform people on the ML
< jonasschnelli>
so we need to change BIPS.md :p
< gmaxwell>
The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
< wumpus>
it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good
< luke-jr>
considering BIP173, it's arguably a bug to fix in backports even ;)
< sipa>
i believe this code actually predates bip173
< gmaxwell>
sipa: it does.
< wumpus>
heh
< achow101>
so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs?
< MarcoFalke>
wallets should send to any address a merchant provides them, but the wallet itself should only generate v1 addresses after the v1 fork activated
< luke-jr>
achow101: inputs*?
< sipa>
achow101: i'd just drop the rule entirely
< luke-jr>
MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion
< gmaxwell>
We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules. Outputs are fine.
< sipa>
maybe we want to independently add a warning in the GUI
< MarcoFalke>
achow101: outputs would be relayed, but spending from them would be non-standard
< luke-jr>
sipa: policy should prevent spending v1 UTXOs
< sipa>
luke-jr: it already does
< achow101>
ah, I see
< luke-jr>
sipa: nah, because of P2Sh stuff
< luke-jr>
sipa: yes, but it sounded like you might be talking about dropping it too
< sipa>
luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed
< sipa>
ah no, i'm only talking about the sending to part
< luke-jr>
k
< sipa>
(which is implemented completely independently)
< gmaxwell>
right thats another point against blocking v1 outputs: It's _impossible_ to block p2sh v1 outputs...
< sdaftuar>
it would be nice to not bother implementing p2sh for v1, i think?
< luke-jr>
and because of ^, I don't think we should warn sending to v1 outputs either
< luke-jr>
sdaftuar: is there a benefit to that?
< achow101>
sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though
< sipa>
that's an independent discussion
< gmaxwell>
There are many ways people can hand you insecure addresses already... I at least don't have any reason to think that insecure future-version addresses are a worse problem than things like copy and pasting example addresses.
< instagibbs>
achow101, you can define it to be illegal tho
< sipa>
jnewbery: what's your opinion?
< instagibbs>
or just leave it undefined
< sdaftuar>
sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible
< gmaxwell>
achow101: we could, for example, close of p2sh embedded spending in the future entirely.
< gmaxwell>
s/of/off/
< jnewbery>
I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them
< gmaxwell>
jnewbery: what do you mean by validate them?
< luke-jr>
^
< jnewbery>
I think people upgrade Bitcoin Core fairly frequently in general, so I can't see this being something that holds up adoption of segwit v1
< gmaxwell>
There normally isn't really any validation of outputs.
< luke-jr>
why does the sender care if the recipient spends it or not
< jnewbery>
I mean that they can be spent
< instagibbs>
sdaftuar, another point to doing that is then you *know* which version you're sending to, up to wallet to guard against edge cases
< jnewbery>
All other things being equal, I'd prefer the wallet not to be able to send to a class of unspendable addresses that we can easily check
< luke-jr>
jnewbery: the sender doesn't know if they can or can't be spent
< sipa>
jnewbery: would you be ok with a GUI-only warning?
< wumpus>
so to be clear: the discussion is about the relay policy, the wallet is a different topic
< jnewbery>
for example, we don't send to v0 with non 42/64 character witnesses
< gmaxwell>
(FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support)
< luke-jr>
jnewbery: it is spendable, just rejected by policy
< gmaxwell>
jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem.
< jnewbery>
I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :)
< wumpus>
the wallet not being able to send to certain addresses doesn't nearly block forward compatiblity as much as a restrictive relay policy does
< sipa>
gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented
< luke-jr>
most nodes are 0.16 still
< jonasschnelli>
I think we should allow sending to v1+ in the wallet and in the GUI
< jnewbery>
Right, my opinion is that the forward-compatibility issue is not a huge issue
< gmaxwell>
most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle...
< wumpus>
jnewbery: you mean not for relaying either?
< luke-jr>
0.16.1 is 50% of all nodes it looks like
< jonasschnelli>
forward compatibility seems to be more important than foot-gun that trigger very very rarely
< jnewbery>
No, I think we should relay sending to V anything
< jonasschnelli>
And we don't (and can't) prevent P2SH forms anyway
< wumpus>
I'm confused now
< jnewbery>
I think we're all in agreement about mempool policy
< wumpus>
so, do we agree on changing this relay policy?
< jonasschnelli>
yes
< sipa>
i think so
< meshcollider>
Yes
< luke-jr>
+1
< achow101>
ack
< gmaxwell>
luke-jr: I think something weird is going on wrt versions, so that figure might be distored. (e.g. run your figures but exclude china...)
< jnewbery>
the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :)
< wumpus>
ok!
< jonasschnelli>
I guess the we are not agreeing about wether the wallet allows to send to v1+
< wumpus>
jnewbery: I think a warning makes sense
< meshcollider>
I'm ok with a wallet warning
< luke-jr>
gmaxwell: Chinese users are real though?
< gmaxwell>
I think a warning is foolish.
< jonasschnelli>
me 2
< luke-jr>
if we could reliably warn, it might be worth considering, but we can't
< gmaxwell>
luke-jr: Yes but I'm not confident that they're users. We can talk offline.
< jonasschnelli>
Assume one will send to v1 with 0.18.0 in one year where we assume having v1
< luke-jr>
becuase of p2sh etc
< jonasschnelli>
(if 0.18.0 would have the warning)
< luke-jr>
jonasschnelli: if warnings were reliable, we could base it on what we see in blocks
< gmaxwell>
I could even see blocking sending, but only up until a certian time.
< jonasschnelli>
I'm sure users would send to the p2sh version of it just thy bypass the warning
< luke-jr>
eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay
< gmaxwell>
But forever warning or blocking is just going to make it so that we can't quickly switch to v1 address generation by default.
< jonasschnelli>
luke-jr: yes. But that complex to implement without knowing the future
< MarcoFalke>
How would the warning be worded?
< luke-jr>
well, because we can't detect it reliably anyway, no point doing it even that way
< gmaxwell>
I feel like the principle of outputs is being lost here.
< luke-jr>
(I suppose we could look for spends getting mined instead)
< gmaxwell>
When a third party provides you with an output, thats it. It is none of your business what their policy is.
< sdaftuar>
gmaxwell: i agree with that
< gmaxwell>
This is one of the underlying principles behind p2sh and later hash based addresses.
< luke-jr>
gmaxwell: good point
< MarcoFalke>
"Warning: You are sending to an address that miners can steal from"?
< gmaxwell>
It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P
< instagibbs>
We can't do anything when someone gives you a bcash address either
< luke-jr>
MarcoFalke: that might not be true though
< jonasschnelli>
Warning if the last <tbd> blocks have no Vx output spent is probably an overkill?
< MarcoFalke>
And the the users go on reddit and ask what it means
< gmaxwell>
MarcoFalke: that warning wouldn't be true after some point in the future.
< MarcoFalke>
s/can/may for a limited time/
< instagibbs>
I'm not sure what warnings would achieve.
< luke-jr>
it would achieve people moving back to P2SH wrappers
< gmaxwell>
instagibbs: good point on the bcash addresses. I've been told that this has been causing some pretty big nussances for some people (mostly the other direction, someone buys bcash thinks its bitcoin and sends it to an exchange bitcoin address....)
< MarcoFalke>
I'd prefer: "Warning: You are sending to a p2sh address"
< instagibbs>
gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing
< jnewbery>
There are currently a lot of high-level design considerations that aren't documented in the codebase. Some of them may exist in individual contributor's gists, or might not be written down at all.
< jnewbery>
Should we try to have some standard location to put them in so it's easier for people to understand why things are the way they are? One suggestion would be to use github's wiki feature.
< instagibbs>
jnewbery, ACK, but note that it's mostly me imagining other people doing the work
< wumpus>
why not the doc folder?
< jnewbery>
Past critical bugs that have been fixed
< achow101>
we have that devwiki repo we use for release notes. could put other docs there
< jonasschnelli>
I also prefer within the sources
< MarcoFalke>
agree with wumpus. Should be in ./doc/
< jonasschnelli>
Also,.. how do we prevent from getting outdated?
< gmaxwell>
I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work.
< MarcoFalke>
jonasschnelli: Yell at people for not updating the docs
< wumpus>
achow101:yes, that would be another option
< jnewbery>
I don't think adding docs should go through the same review process as code changes
< gmaxwell>
Maybe put a boiler plate header on them that they could be outdated.
< jnewbery>
gmaxwell: github wikis are repos. You can clone them locally
< gmaxwell>
and add a last updated date to each document or something.
< wumpus>
jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point
< MarcoFalke>
jnewbery: yes they should. Wrong documentation is more harmful than no documentation
< gmaxwell>
even having it in the history is useful too.
< luke-jr>
IMO it should be separate from the code.
< wumpus>
but I like the idea, if anyone is willing to write this ata ll
< luke-jr>
this is an easy case to modularise; it has no ties to our versions/branches
< sipa>
i like the idea of putting a "Last updated at" + warning it could be outdated
< sdaftuar>
MarcoFalke: wait what, wrong documentation is more harmful than nothing? can you explain?
< gmaxwell>
I don't really care what repo its in, just should be in some repo for sure. :)
< jnewbery>
I'm not suggesting that someone goes and writes a bunch of documentation. I'm suggesting that people who want to contribute documentation should have somewhere to put it.
< instagibbs>
to motivate this, things like p2p design are basically in the heads of a handful of people, I've never seen it written down anywhere aside from IRC
< wumpus>
sdaftuar: because it gets people to waste time, thinking of solutions based on the documentation, then it doesn't really apply to the current code base anymore
< MarcoFalke>
sdaftuar: I was talking about review
< gmaxwell>
sdaftuar: I'm also of the view that wrong documentation can be worse than nothing. ::shrugs:: it isn't always. Depends on the recipent and how the wrong doc was written.
< MarcoFalke>
not about outdated documentation
< gmaxwell>
(okay maybe not also)
< sdaftuar>
wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs
< gmaxwell>
But I still think it's worth doing even if it ends up outdated.
< wumpus>
wrong code comments can cause a lot of damage, maybe less so for high level docs
< gmaxwell>
Its just somewhat important the the text itself reflect the possibility of it being outdated.
< MarcoFalke>
agree that outdated (timestamped) documentation is helpful
< sdaftuar>
anyway i would certainly appreciate having a place to put docs that i have written, so if we can decide to put stuff like that anywhere, i will happily contribute
< jnewbery>
An argument for a wiki and not in the PR is that we won't get a bunch of helpful new contributors opening PRs to fix spelling in the docs
< wumpus>
well, put it in the wiki then
< jnewbery>
*not in the repo
< wumpus>
everyone has write access to that one :)
< gmaxwell>
Is a bunch of spelling fixes important? :P
< luke-jr>
github wikis are just git repos
< jnewbery>
I don't think it exists for bitcoin/bitcoin
< wumpus>
gmaxwell:not important, but I agree re: PR bottlenecks
< MarcoFalke>
which is the downside that anyone can vandalize
< wumpus>
jnewbery: it doesn't for access control
< wumpus>
jnewbery: please use the devwiki
< MarcoFalke>
how hard is it to run a spellchecker these days?
< wumpus>
#topic opportunity to provide feedback with GitHub CEO (moneyball)
< instagibbs>
you gotta add sudo
< MarcoFalke>
moneyball is github ceo?
< moneyball>
so jimpo and i received an email from a guy at github: I run a program for our CEO Nat Friedman connecting him with community members in GitHub. It’s an hour long chat on Friday’s where you can talk about anything GitHub that’s on your mind. I was wondering if you all would like to join us. You’re welcome to bring other maintainers up to a max of about 7 people. Many groups bring a “top 10” list with
< moneyball>
them and we go through that. We also have some demos and mockups of stuff to show and then discuss. Tell us how to improve GitHub.
< wumpus>
(I don't really have anything to discuss wrt hardcoded seeds at the moment)
< meshcollider>
wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself
< MarcoFalke>
wumpus: ok
< instagibbs>
moneyball, sorry who is "we" wrt demos
< cfields>
moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity.
< moneyball>
This is an opportunity for the project to communicate 1) annoying bugs/reliability issues 2) new feature requests 3) maybe what it would take for the project to be comfortable using GitHub long-term
< gmaxwell>
sounds good for people with opinions. :)
< cfields>
(we=DCI)
< moneyball>
I am happy to attend this but (a) we need to compile a list (b) it would really be better if at least 1 other dev joined me who has deeper experience with the top 10 list than I do
< cfields>
instagibbs: lol, sorry, that wasn't in response to you.
< luke-jr>
open source github? :p
< MarcoFalke>
feature request: Nicely display pgp signed comments
< wumpus>
meshcollider: maybe, but once you want to lock down access, the only mechanism is the list of people with write access to the repo, which is the people with commit access
< moneyball>
luke-jr: i'd say nothing is off-limits!
< luke-jr>
MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea
< MarcoFalke>
Just display, not verifying
< jonasschnelli>
Probably interested people should form a list of feature requests and/or bugs (gist or wiki)
< instagibbs>
stop having commits reported in git commit timestamp order :P
< moneyball>
instagibbs: "we" is github
< jonasschnelli>
No need to post your feature request here and now
< sipa>
yeah
< luke-jr>
instagibbs: that's git-log's default too though
< moneyball>
yeah i am not intending to create the list right now in this meeting
< jonasschnelli>
moneyball: Thanks and great opportunity I agree
< cfields>
moneyball: I'd be interested.
< moneyball>
i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me
< gmaxwell>
if someone makes a list I'll dump some gripes in and other people can decide if they agree or think they're important.
< gwillen>
instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order
< gwillen>
there has been an open issue on this for a fucking age
< meshcollider>
It is in-person right, not remote attendance?
< sipa>
maybe open an issue on our tracker, where people can comment with things to mention?
< sipa>
(also, ack topo sort; i've personnally asked them for this years ago)
< MarcoFalke>
+1 instagibbs suggestion
< jnewbery>
yes please!
< moneyball>
sipa: i will do that
< wumpus>
what I"d like is to be able to do finer permission control, e.g. be able to give people access to issues/PR management without giving them write and merge access to the repo
< sipa>
moneyball: thanks
< moneyball>
if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub
< luke-jr>
wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient
< moneyball>
in the mean time please contribute to the Issue i'll create. i'll post it here once created.
< meshcollider>
Sounds good
< cfields>
I think it'd be most useful for us to discuss things that are paranoia-related, since that's what's most interesting about us to them, I'd think.
< wumpus>
luke-jr: well if 'checker script' is sufficiently general, sure, though I wouldn't want to include the entirety of travis in there, such a check needs to be fast
< cfields>
Things like "display order" they'll hear from everyone.
< ryanofsky>
my github feature request would be ability to base prs on top of other prs (just hide commits from base pr)
< luke-jr>
wumpus: eg, just the PGP checks
< jnewbery>
They should hear it from everyone!
< luke-jr>
ryanofsky: ooh, good idea
< meshcollider>
I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to
< gmaxwell>
luke-jr: that was exactly my thought.
< sipa>
cfields: good point
< gmaxwell>
(re enforce pgp allowing for access split)
< jonasschnelli>
paranoid-mode would probably exclude using github
< cfields>
ok, maybe s/paranoia-related/related to the way we use github uniquely/
< sipa>
cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns
< cfields>
sipa: yes, right.
< wumpus>
jonasschnelli:yes, I think that's a very slippery slope :)
< gwillen>
cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years
< sipa>
any other topics?
< instagibbs>
6 min left
< gmaxwell>
gwillen: thre just may be an arch reason as to why its hard.
< luke-jr>
one thing I would find useful: a way for email notifications to distinguish between general project stuff, and stuff specifically I'm invovled in, and stuff I'm specifically mentioned in
< wumpus>
don't think so
< gwillen>
so if they're literally asking us for feedback, it would be good to say "why are you ignoring community feedback, please listen to it"
< luke-jr>
right now I often just ignore github notifications in bulk because there's so many, and don't see when people ask me things
< ryanofsky>
luke-jr, i think that already exists, you can filter based on to address
< wumpus>
luke-jr:there is, you acn filter on author@github.com and things like that
< cfields>
moneyball: maybe you can provide some context for why they reached out to us specifically?
< gmaxwell>
I mean. there is a lot of little stuff, like they were totally unable to keep randos from taking over the attribution on imported commits, but we eventually 'fixed' that by creating a dummy account. I don't think this is worth discussing, since we 'fixed it' but its still kind of embarassing on their part.
< moneyball>
jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us
< luke-jr>
wumpus: I don't understand
< jonasschnelli>
But never forget, they need community feedback to improve to earn money for corporate customers
< jonasschnelli>
*from
< ryanofsky>
luke-jr, if you want to filter mentions look for Mention <mention@noreply.github.com> in To: header
< gwillen>
gmaxwell: I definitely agree on focusing on active problems with no good workaround
< wumpus>
luke-jr there's a special to-address they'll add in those cases fornmentions
< cfields>
moneyball: heh, gotcha. Thanks.
< luke-jr>
hmm
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Apr 18 19:57:44 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< bitcoin-git>
[bitcoin] sipa opened pull request #15846: [POLICY] Make sending to future native witness outputs standard (master...201904_futuresegwitstandard) https://github.com/bitcoin/bitcoin/pull/15846
< gwillen>
gmaxwell: I would say the right focus is on impact-to-us in our issues, which does not rule out little things if they are actively causing problems
< gwillen>
I think it's better to get them to fix supid little shit than to ask them for important things they'll never do
< cfields>
moneyball: Thanks for bringing that up!
< gwillen>
(but obviously both would be nice)
< luke-jr>
wumpus: thanks
< gmaxwell>
gwillen: like eons back I was talking to someone at github and telling them that I wanted a feature where you could set a repo so that newly created issues / PRs would only be visible to the submitter/project contribs (or at least logged in users) for 24 hours or whatever, in order to cut down abuse of github for trolling... and the reply was that sort of thing wouldn't be a popular feature in
< gmaxwell>
github because it would retard account growth.
< gmaxwell>
Maybe that would be less important now.
< gwillen>
I think this is exactly the sort of thing to bring up when they think we're important enough to ask us for feedback
< gmaxwell>
(that was motivated by a couple instances where some trolling jerk opened a PR to do some dumb change then went and spammed reddit with CORE DEVS GONNA XXX!)
< gwillen>
(I do agree it's also a good opportunity to bring up philosophically-aligned stuff about privacy and trust)
< instagibbs>
would also be nice so i dont have to read "ACTIVATED 1GB BLOCKS" PRs
< instagibbs>
as a non-maintainer
< gmaxwell>
I'm not sure how much of that is just my dislike of the modern 'everyone can scribble on everything' web. :P
< wumpus>
it would have been nice, with better people
< gwillen>
"better people" would solve many problems, but it was not to be
< sipa>
like the need for bitcoin?
< wumpus>
^^
< gwillen>
heh!
< gwillen>
gmaxwell: in seriousness I think better anti-troll features would be huge for github in light of its increasing use as a Social Netowkr
< gwillen>
and also as a platform for grandstanding
< gmaxwell>
(related, githubs anti-spam has burned us a couple times with them vanishing perfectly reasonable comments without a trace and it looking like we deleted them)
< gwillen>
this would help with all the "rar I want to make a political statement against your repository" issues
< gwillen>
since there would no longer be a motivation to file them if they could be moderated before publication
< gmaxwell>
yup.
< jonasschnelli>
If I could ask for a feature, then it would be making github commit order rebase save
< gmaxwell>
gwillen: Also it would be less stressful to deal with them.
< gwillen>
jonasschnelli: is this the same as the toposort thing we were discussing upthread
< gwillen>
or a different issue
< gmaxwell>
just another idiot with an offtopic request, ... ploink.
< gmaxwell>
vs oh god inescapable dramafest.
< jonasschnelli>
gwillen: I don't know what toposort refers to... but then one I mentioned is that once you do a rebase, the commit order it messed up
< bitcoin-git>
bitcoin/0.18 a4fc2fb Wladimir J. van der Laan: gui: Pre-rc4 translations update
< kanzure>
why is bitcoin-git exiting so frequently. can we fix this?
< sipa>
it joins for every message
< gwillen>
it is not a persistent process, it is stateless, so it can't stay joined when not messaging
< luke-jr>
if we remove the +n on the channel, it can send without joining
< luke-jr>
this may or may not be spam suicide though
< gwillen>
right
< gwillen>
probably better to tolerate a few extra lines
< wumpus>
we had that in the past, but it's not a good idea
< gwillen>
I'm not sure how -n interacts with bans, it might make them ineffective
< wumpus>
FWIW in general it can be pretty useful to disable join/part notifications for busy channels like this
< bitcoin-git>
[bitcoin] darosior opened pull request #15848: Add a check for free disk space at first startup. ref #15813 (master...check_free_disk_size) https://github.com/bitcoin/bitcoin/pull/15848
< luke-jr>
wumpus: my client only does it globally
< bitcoin-git>
bitcoin/0.18 4384839 Wladimir J. van der Laan: doc: Move release notes from wiki
< sdaftuar>
laanwj: i was just trying to edit the wiki to remove mention of 14897 from the release notes
< sdaftuar>
er wumpus ^^
< sdaftuar>
i guess there are other edits that still need to be made as well, should we just do that via PR between now and final release?
< wumpus>
sdaftuar: uhmm
< wumpus>
sdaftuar: I see various TODOs by Pieter are also still in there
< sdaftuar>
yeah i just saw that too
< wumpus>
for this reason I prefer to leave merging back the release notes for -final instead of a rc
< wumpus>
but yes, only way to edit it now is on the branch
< sdaftuar>
ok sounds good
< gmaxwell>
why doesn't the bot just stay in all the time?
< wumpus>
ready to tag rc4?
< gwillen>
gmaxwell: it can't, it's stateless
< wumpus>
gmaxwell: gwillen | it is not a persistent process, it is stateless, so it can't stay joined when not messaging
< wumpus>
it's a design choice
< wumpus>
it'd certainly be possible to have a persistent bot, but, github's own notification did exactly the same as this and that's what we ported
< wumpus>
FWIW source for the bot is here, I guess persistent bot functionality would be welcome if anyone implemented it: https://github.com/gkrizek/ghi
< gmaxwell>
luke-jr: I've been monitoring not just what versions I see out there, but also hosts that connect to me that are fetching old blocks-- IOW ones that look like they're syncing up.
< gmaxwell>
luke-jr: and I've noticed that almost all syncing up hosts I see are 0.16.1 and coming from a relatively small number of networks in china.
< gmaxwell>
Which made me wonder if perhaps some chinese language docs pointed to an outdated download... but jl2012 was unable to find anything.
< gmaxwell>
also their behavior appears to be weird, e.g. I see them downloading a moderate number of blocks then stop and stay connected.
< luke-jr>
gmaxwell: hmm, any relation to the networks?
< gmaxwell>
beyond 'china' I'm not aware of anything that links these hosts.
< bitcoin-git>
[bitcoin] jamesob opened pull request #15849: Thread names in logs and deadlock debug tools (master...2018-05-threadnames-take-2) https://github.com/bitcoin/bitcoin/pull/15849
< gmaxwell>
Every network in that list is china, and thats also doubly intresting considering the historic near absence of bitcoin nodes in china.
< luke-jr>
hrm
< gmaxwell>
so I think either something is causing chinese language users to use 0.16.1 or that there is some DOS attack or attack prep that happens to currently look like 0.16.1.
< gmaxwell>
if it is confused users I still don't know why there are so many.
< gmaxwell>
in the past week-ish I've observed 1395 distinct chinese IPs syncing old blocks with 0.16.1. And like ... 2 hosts that weren't chinese 0.16.1.
< gmaxwell>
(and were syncing old blocks)
< gmaxwell>
if nothing else it might make sense for you to make a versions page that split china and the rest of the world, so we could see if there was a chinese language specific issue with running old versions.
< midnightmagic>
appliance maybe
< gmaxwell>
possibly.
< luke-jr>
gmaxwell: my methodology is incompatible with splitting by region, sadly