19:00:04 <wumpus> #startmeeting
19:00:04 <lightningbot> Meeting started Thu Apr 18 19:00:04 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:04 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:14 <jnewbery> hi
19:00:17 <kanzure> hi
19:00:28 <sipa> hi
19:00:33 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
19:00:42 <achow101> hi
19:00:46 <jonasschnelli_> hi
19:00:53 <jamesob> hi
19:00:55 <meshcollider> hi
19:00:56 <MarcoFalke> when rc4?
19:01:07 <wumpus> #topic 0.18.0rc4
19:01:21 <jonasschnelli_> I guess #15839 is holding it back
19:01:23 <gribble> https://github.com/bitcoin/bitcoin/issues/15839 | [0.18] Revert GetData randomization change (#14897) by sdaftuar · Pull Request #15839 · bitcoin/bitcoin · GitHub
19:01:30 <MarcoFalke> Needs merge
19:01:42 <wumpus> that seems to be the only one left?
19:01:54 <MarcoFalke> yeah, after that I think we are good to tag rc4
19:01:59 <wumpus> good to know
19:02:09 <gmaxwell> oh I thought the revert was merged already.
19:02:38 <wumpus> ok, let's merge that one and tag rc4 after the meeting
19:02:43 <sipa> ack
19:02:46 <jonasschnelli> ack
19:02:50 <MarcoFalke> #action merge 15839 and tag rc4
19:03:27 <wumpus> #topic High priority for review
19:03:39 <wumpus> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+project%3Abitcoin%2Fbitcoin%2F8  6 PRs on there right now
19:04:33 <wumpus> anything to add/remove? I guess everyone does this outside of the meetings nowadays
19:04:48 <sipa> can i have 15427?
19:04:59 <sipa> #15427
19:05:01 <gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
19:05:02 <MarcoFalke> can I have #15758?
19:05:04 <gribble> https://github.com/bitcoin/bitcoin/issues/15758 | qa: Add further tests to wallet_balance by MarcoFalke · Pull Request #15758 · bitcoin/bitcoin · GitHub
19:05:05 <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
19:05:41 <jnewbery> gwillen asked for #15024 to go in after the last wallet meeting
19:05:43 <gribble> https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub
19:06:07 <gwillen> jnewbery: thanks, I was just trying to find that but I'm on an airplane with bad wifi
19:06:21 <wumpus> sipa MarcoFalke added
19:06:27 <MarcoFalke> thx
19:06:40 <sipa> thanks
19:07:03 <wumpus> also added
19:07:12 <gwillen> +1 thanks!
19:07:30 <wumpus> looks like both achow101 and sdaftuar have two PRs on the list now :o
19:07:45 <achow101> oops
19:08:05 <jonasschnelli> sdaftuar will resolve now
19:08:14 <wumpus> can/should we make a choice what to keep on there?
19:08:16 <MarcoFalke> If they were suggested by different people, it should be fine
19:08:17 <sipa> i propose a trial by combat to determine whose PRs remain
19:08:34 <MarcoFalke> Everyone can suggest one pr (it doesn't have to be their own)
19:08:39 <instagibbs> is your PR heavier than a duck
19:08:40 <wumpus> sipa:everyone gets to have one PR
19:08:51 <wumpus> MarcoFalke: hmm
19:08:57 <achow101> instagibbs: how many lines of code does a duck weigh?
19:08:59 <gmaxwell> Yes, but based on who proposed.
19:08:59 <jonasschnelli> MarcoFalke: that really hard to keep the overview
19:09:03 <gmaxwell> not who authored.
19:09:07 <wumpus> I don't really care but it's kind of getting out of hand
19:09:12 <gmaxwell> (or that was my understanding)
19:09:13 <MarcoFalke> but I agree that achow101 and sdaftuar should pick one pull that stays
19:09:16 <wumpus> jonasschnelli: yeah, exactly
19:09:23 <jonasschnelli> How do we keep track who proposed?
19:09:24 <wumpus> github doesn't track this
19:09:43 <MarcoFalke> remove NOTFOUND for sdaftuar
19:09:44 <achow101> let's remove #15741 for now. it needs to be rebased anyways
19:09:46 <wumpus> so are all 9 things on the list proposed by different people?
19:09:46 <gribble> https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub
19:09:56 <wumpus> ok
19:10:29 <wumpus> thank you, done
19:10:30 <gmaxwell> In the future we can use some greppable line in IRC to record requests.
19:10:56 <wumpus> 7 PRs on the list now, that's just about managebale
19:11:03 <wumpus> any other topics?
19:11:10 <moneyball> there are 4
19:11:14 <MarcoFalke> moneyball: has a bunch
19:11:16 <moneyball> https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
19:11:24 <jonasschnelli> We could also add a project column per non-author-proposer
19:11:36 <jonasschnelli> I don't expect we would have a lot
19:11:44 <wumpus> moneyball: thanks
19:12:09 <wumpus> #topic Should send-to-non-v0-witness be standard (sipa)
19:12:15 <sipa> hi
19:12:28 <sipa> so we currently have two policy rules w.r.t. future segwit versions
19:12:51 <sipa> one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard
19:12:52 <wumpus> jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards'
19:13:07 <sipa> the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard
19:13:35 <sipa> i believe that first rule does more harm than good
19:14:05 <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.
19:14:09 <meshcollider> I'm inclined to agree
19:14:18 <gmaxwell> I agree the first rule does more harm than good.
19:14:20 <sipa> i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late
19:14:34 <sipa> so if we want that rule, i believe it belongs in the wallet, not in relay policy
19:14:36 <MarcoFalke> No wallet should create thos addresses
19:14:47 <luke-jr> (getting stuck is a problem because it locks up your change)
19:14:57 <gmaxwell> To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets.
19:15:09 <sdaftuar> sipa: are you suggesting it should be wallet rule to not send to those addresses?
19:15:25 <sipa> sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet
19:15:30 <gmaxwell> ugh.
19:15:48 <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
19:15:57 <jnewbery> Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction
19:16:06 <wumpus> I tend to agree, this selfs a self-sabotaging relay policy
19:16:21 <sipa> sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :)
19:16:22 <jnewbery> I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay
19:16:26 <luke-jr> tangent: if relay policy allows it, maybe it should always allow RBF on it?
19:16:50 <sipa> jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best
19:16:52 <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
19:16:53 <gmaxwell> jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity.
19:16:57 <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?
19:17:17 <sipa> luke-jr: yup
19:17:18 <wumpus> forward compatibility is kind of useful
19:17:22 <meshcollider> Exactly...
19:17:23 <gmaxwell> and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address.
19:17:49 <sipa> yeah, i think my preference is not having the rule in the first place
19:17:50 <luke-jr> IMO allow relay and wallet, but force RBF opt-in ;)
19:17:59 <jnewbery> delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15
19:18:05 <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.
19:18:06 <meshcollider> So I also dont think the wallet should refuse to send either, a warning at most
19:18:08 <jnewbery> it's caused by other wallets and exchanges in the ecosystem
19:18:15 <gmaxwell> We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
19:18:23 <luke-jr> jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do
19:18:30 <sdaftuar> luke-jr: +1
19:18:43 <jnewbery> which is not send to non-v0 until there is a defined v1
19:18:56 <wumpus> a warning would be okey
19:18:57 <achow101> the fact that it's not a relay policy will lock up change
19:18:58 <gmaxwell> We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves
19:19:05 <wumpus> but I think we agree, this should not be relay policy
19:19:17 <sipa> i'll PR removing it from relay policy
19:19:21 <wumpus> relay policy has never been used to protect users, if so, why no excessive fee check?
19:19:31 <sipa> wumpus: exactly
19:19:31 <jonasschnelli> indeed
19:19:32 <gmaxwell> wumpus: kinda one sec on that point.
19:19:33 <instagibbs> sipa, it's worth a mailing list email?
19:19:35 <jnewbery> I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1
19:19:55 <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.
19:19:58 <jonasschnelli> instagibbs: seems to be Core policy,... no need for ML?!
19:20:01 <luke-jr> jnewbery: but then we could just as well make a new address format for every version
19:20:05 <gmaxwell> wumpus: but for _output types_ this doesn't apply.
19:20:11 <wumpus> gmaxwell:right
19:20:11 <cfields> replace-by-version? :p
19:20:23 <MarcoFalke> jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated
19:20:26 <luke-jr> jonasschnelli: it seems likely a topic other software would want to consider and act on too
19:20:27 <sipa> actually
19:20:28 <instagibbs> jonasschnelli, people may have made assumptions based on current policy, right or wrong?
19:20:32 <jnewbery> luke-jr: that' not the same at all. This is a one-line (or config) or config
19:20:35 <gmaxwell> jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets.
19:20:38 <sipa> this is a violation of BIP173
19:20:45 <gmaxwell> sipa: correct.
19:20:47 <sipa> "Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. "
19:20:47 <jonasschnelli> oh
19:21:02 <wumpus> it makes sense to inform people on the ML
19:21:08 <jonasschnelli> so we need to change BIPS.md :p
19:21:15 <gmaxwell> The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
19:21:41 <wumpus> it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good
19:21:48 <luke-jr> considering BIP173, it's arguably a bug to fix in backports even ;)
19:21:48 <sipa> i believe this code actually predates bip173
19:21:58 <gmaxwell> sipa: it does.
19:21:59 <wumpus> heh
19:22:01 <achow101> so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs?
19:22:10 <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
19:22:11 <luke-jr> achow101: inputs*?
19:22:35 <sipa> achow101: i'd just drop the rule entirely
19:22:47 <luke-jr> MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion
19:22:50 <gmaxwell> We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules.  Outputs are fine.
19:22:53 <sipa> maybe we want to independently add a warning in the GUI
19:23:03 <MarcoFalke> achow101: outputs would be relayed, but spending from them would be non-standard
19:23:05 <luke-jr> sipa: policy should prevent spending v1 UTXOs
19:23:13 <sipa> luke-jr: it already does
19:23:14 <achow101> ah, I see
19:23:16 <luke-jr> sipa: nah, because of P2Sh stuff
19:23:34 <luke-jr> sipa: yes, but it sounded like you might be talking about dropping it too
19:23:36 <sipa> luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed
19:23:48 <sipa> ah no, i'm only talking about the sending to part
19:23:52 <luke-jr> k
19:23:57 <sipa> (which is implemented completely independently)
19:24:07 <gmaxwell> right thats another point against blocking v1 outputs:  It's _impossible_ to block p2sh v1 outputs...
19:24:25 <sdaftuar> it would be nice to not bother implementing p2sh for v1, i think?
19:24:27 <luke-jr> and because of ^, I don't think we should warn sending to v1 outputs either
19:25:01 <luke-jr> sdaftuar: is there a benefit to that?
19:25:14 <achow101> sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though
19:25:16 <sipa> that's an independent discussion
19:25:22 <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.
19:25:29 <instagibbs> achow101, you can define it to be illegal tho
19:25:39 <sipa> jnewbery: what's your opinion?
19:25:41 <instagibbs> or just leave it undefined
19:25:43 <sdaftuar> sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible
19:25:46 <gmaxwell> achow101: we could, for example, close of p2sh embedded spending in the future entirely.
19:25:58 <gmaxwell> s/of/off/
19:26:04 <jnewbery> I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them
19:26:23 <gmaxwell> jnewbery: what do you mean by validate them?
19:26:27 <luke-jr> ^
19:26:38 <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
19:26:42 <gmaxwell> There normally isn't really any validation of outputs.
19:26:44 <luke-jr> why does the sender care if the recipient spends it or not
19:26:45 <jnewbery> I mean that they can be spent
19:27:11 <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
19:27:14 <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
19:27:23 <luke-jr> jnewbery: the sender doesn't know if they can or can't be spent
19:27:27 <sipa> jnewbery: would you be ok with a GUI-only warning?
19:27:29 <wumpus> so to be clear: the discussion is about the relay policy, the wallet is a different topic
19:27:39 <jnewbery> for example, we don't send to v0 with non 42/64 character witnesses
19:27:45 <gmaxwell> (FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support)
19:27:49 <luke-jr> jnewbery: it is spendable, just rejected by policy
19:28:02 <gmaxwell> jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem.
19:28:09 <jnewbery> I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :)
19:28:13 <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
19:28:16 <sipa> gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented
19:28:29 <luke-jr> most nodes are 0.16 still
19:28:41 <jonasschnelli> I think we should allow sending to v1+ in the wallet and in the GUI
19:28:50 <jnewbery> Right, my opinion is that the forward-compatibility issue is not a huge issue
19:28:54 <gmaxwell> most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle...
19:29:11 <wumpus> jnewbery: you mean not for relaying either?
19:29:18 <luke-jr> 0.16.1 is 50% of all nodes it looks like
19:29:19 <jonasschnelli> forward compatibility seems to be more important than foot-gun that trigger very very rarely
19:29:25 <jnewbery> No, I think we should relay sending to V anything
19:29:31 <jonasschnelli> And we don't (and can't) prevent P2SH forms anyway
19:29:43 <wumpus> I'm confused now
19:30:01 <jnewbery> I think we're all in agreement about mempool policy
19:30:03 <wumpus> so, do we agree on changing this relay policy?
19:30:09 <jonasschnelli> yes
19:30:10 <sipa> i think so
19:30:11 <meshcollider> Yes
19:30:21 <luke-jr> +1
19:30:25 <achow101> ack
19:30:25 <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...)
19:30:26 <jnewbery> the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :)
19:30:30 <wumpus> ok!
19:30:37 <jonasschnelli> I guess the we are not agreeing about wether the wallet allows to send to v1+
19:30:44 <wumpus> jnewbery: I think a warning makes sense
19:30:45 <meshcollider> I'm ok with a wallet warning
19:30:50 <luke-jr> gmaxwell: Chinese users are real though?
19:30:55 <gmaxwell> I think a warning is foolish.
19:31:01 <jonasschnelli> me 2
19:31:13 <luke-jr> if we could reliably warn, it might be worth considering, but we can't
19:31:16 <gmaxwell> luke-jr: Yes but I'm not confident that they're users. We can talk offline.
19:31:20 <jonasschnelli> Assume one will send to v1 with 0.18.0 in one year where we assume having v1
19:31:22 <luke-jr> becuase of p2sh etc
19:31:40 <jonasschnelli> (if 0.18.0 would have the warning)
19:31:54 <luke-jr> jonasschnelli: if warnings were reliable, we could base it on what we see in blocks
19:31:57 <gmaxwell> I could even see blocking sending, but only up until a certian time.
19:32:06 <jonasschnelli> I'm sure users would send to the p2sh version of it just thy bypass the warning
19:32:10 <luke-jr> eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay
19:32:28 <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.
19:32:29 <jonasschnelli> luke-jr: yes. But that complex to implement without knowing the future
19:32:39 <MarcoFalke> How would the warning be worded?
19:32:40 <luke-jr> well, because we can't detect it reliably anyway, no point doing it even that way
19:33:05 <gmaxwell> I feel like the principle of outputs is being lost here.
19:33:08 <luke-jr> (I suppose we could look for spends getting mined instead)
19:33:25 <gmaxwell> When a third party provides you with an output, thats it. It is none of your business what their policy is.
19:33:37 <sdaftuar> gmaxwell: i agree with that
19:33:42 <gmaxwell> This is one of the underlying principles behind p2sh and later hash based addresses.
19:33:55 <luke-jr> gmaxwell: good point
19:33:58 <MarcoFalke> "Warning: You are sending to an address that miners can steal from"?
19:33:59 <gmaxwell> It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P
19:33:59 <instagibbs> We can't do anything when someone gives you a bcash address either
19:34:06 <luke-jr> MarcoFalke: that might not be true though
19:34:09 <jonasschnelli> Warning if the last <tbd> blocks have no Vx output spent is probably an overkill?
19:34:15 <MarcoFalke> And the the users go on reddit and ask what it means
19:34:18 <gmaxwell> MarcoFalke: that warning wouldn't be true after some point in the future.
19:34:35 <MarcoFalke> s/can/may for a limited time/
19:34:38 <instagibbs> I'm not sure what warnings would achieve.
19:35:09 <luke-jr> it would achieve people moving back to P2SH wrappers
19:35:13 <instagibbs> lol
19:35:17 <sdaftuar> yuck!
19:35:22 <gmaxwell> and still sending to v1
19:35:24 <gmaxwell> :P
19:35:29 <luke-jr> right
19:36:12 <wumpus> time for next topic, I think
19:36:16 <jnewbery> +1
19:36:22 <wumpus> #topic Bitcoin Core design documentation (jnewbery)
19:36:25 <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....)
19:36:31 <MarcoFalke> I'd prefer: "Warning: You are sending to a p2sh address"
19:36:48 <instagibbs> gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing
19:37:04 <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.
19:37:15 <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.
19:37:30 <jnewbery> Examples: P2P banning/disconnecting design philosophy
19:37:35 <instagibbs> jnewbery, ACK, but note that it's mostly me imagining other people doing the work
19:37:41 <wumpus> why not the doc folder?
19:37:46 <jnewbery> Past critical bugs that have been fixed
19:37:49 <achow101> we have that devwiki repo we use for release notes. could put other docs there
19:37:58 <jonasschnelli> I also prefer within the sources
19:38:04 <MarcoFalke> agree with wumpus. Should be in ./doc/
19:38:10 <jonasschnelli> Also,.. how do we prevent from getting outdated?
19:38:22 <gmaxwell> I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work.
19:38:24 <MarcoFalke> jonasschnelli: Yell at people for not updating the docs
19:38:26 <wumpus> achow101:yes, that would be another option
19:38:33 <jnewbery> I don't think adding docs should go through the same review process as code changes
19:38:36 <gmaxwell> Maybe put a boiler plate header on them that they could be outdated.
19:38:44 <jnewbery> gmaxwell: github wikis are repos. You can clone them locally
19:38:47 <gmaxwell> and add a last updated date to each document or something.
19:38:51 <wumpus> jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point
19:39:06 <MarcoFalke> jnewbery: yes they should. Wrong documentation is more harmful than no documentation
19:39:08 <gmaxwell> even having it in the history is useful too.
19:39:28 <luke-jr> IMO it should be separate from the code.
19:39:37 <wumpus> but I like the idea, if anyone is willing to write this ata ll
19:39:47 <luke-jr> this is an easy case to modularise; it has no ties to our versions/branches
19:39:49 <sipa> i like the idea of putting a "Last updated at" + warning it could be outdated
19:39:55 <sdaftuar> MarcoFalke: wait what, wrong documentation is more harmful than nothing?  can you explain?
19:40:21 <gmaxwell> I don't really care what repo its in, just should be in some repo for sure. :)
19:40:30 <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.
19:40:41 <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
19:40:54 <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
19:41:04 <MarcoFalke> sdaftuar: I was talking about review
19:41:09 <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.
19:41:11 <MarcoFalke> not about outdated documentation
19:41:21 <gmaxwell> (okay maybe not also)
19:41:28 <sdaftuar> wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs
19:41:38 <gmaxwell> But I still think it's worth doing even if it ends up outdated.
19:42:05 <wumpus> wrong code comments can cause a lot of damage, maybe less so for high level docs
19:42:09 <gmaxwell> Its just somewhat important the the text itself reflect the possibility of it being outdated.
19:42:18 <MarcoFalke> agree that outdated (timestamped) documentation is helpful
19:42:27 <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
19:42:29 <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
19:42:51 <wumpus> well, put it in the wiki then
19:42:54 <jnewbery> *not in the repo
19:42:59 <wumpus> everyone has write access to that one :)
19:43:06 <gmaxwell> Is a bunch of spelling fixes important? :P
19:43:11 <luke-jr> github wikis are just git repos
19:43:17 <jnewbery> I don't think it exists for bitcoin/bitcoin
19:43:19 <wumpus> gmaxwell:not important, but I agree re: PR bottlenecks
19:43:20 <MarcoFalke> which is the downside that anyone can vandalize
19:43:26 <wumpus> jnewbery: it doesn't for access control
19:43:31 <wumpus> jnewbery: please use the devwiki
19:43:34 <MarcoFalke> how hard is it to run a spellchecker these days?
19:43:36 <wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
19:43:39 <luke-jr> MarcoFalke: can address that when/if it happens
19:43:47 <MarcoFalke> ok
19:43:52 <jnewbery> why not a wiki in bitcoin/bitcoin?
19:44:00 <luke-jr> jnewbery: because it's Core-specific?
19:44:02 <wumpus> because it'd only be writabel by people with commit access
19:44:06 <jnewbery> ah
19:44:06 <luke-jr> (and if it isn't, we have BIPs)
19:44:08 <sipa> we could also see from time to time whether a wiki article is sufficiently mature and stable to include it in the doc/ directory directly
19:44:19 <gmaxwell> Also be careful with making publically writable stuff in bitcoin/bitcoin.
19:44:19 <wumpus> the only way to do delegation on github is to have multiple repos
19:44:32 <wumpus> gmaxwell: yes, I don't want that
19:44:42 <jonasschnelli> gmaxwell: indeed
19:44:44 <gmaxwell> "ATTENTION. OLD BITCOIN IS VULNERABLE. DOWNLOAD HOTFIX NOW  http://secure.haxor.com/bitcoin.exe"
19:44:55 <MarcoFalke> hmmm
19:44:56 <sdaftuar> ouch :(
19:45:00 <wumpus> no need to throw everything in the same place
19:45:01 <jonasschnelli> heh
19:45:12 <jnewbery> ok, thanks. Sounds like https://github.com/bitcoin-core/bitcoin-devwiki/wiki is the place
19:45:15 <luke-jr> gmaxwell: 404
19:45:23 <sipa> lol
19:45:25 <MarcoFalke> 15 minutes left. Next topic
19:45:27 <jonasschnelli> rofl
19:45:40 <luke-jr> but wait, I need to get the hotfix!
19:45:44 <gmaxwell> luke-jr: "wine <urlib error>: 404"
19:45:49 <wumpus> #topic opportunity to provide feedback with GitHub CEO (moneyball)
19:46:01 <instagibbs> you gotta add sudo
19:46:06 <MarcoFalke> moneyball is github ceo?
19:46:07 <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
19:46:07 <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.
19:46:18 <wumpus> (I don't really have anything to discuss wrt hardcoded seeds at the moment)
19:46:25 <meshcollider> wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself
19:46:39 <MarcoFalke> wumpus: ok
19:46:43 <instagibbs> moneyball, sorry who is "we" wrt demos
19:46:52 <cfields> moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity.
19:47:04 <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
19:47:06 <gmaxwell> sounds good for people with opinions. :)
19:47:07 <cfields> (we=DCI)
19:47:32 <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
19:47:33 <cfields> instagibbs: lol, sorry, that wasn't in response to you.
19:47:34 <luke-jr> open source github? :p
19:47:42 <MarcoFalke> feature request: Nicely display pgp signed comments
19:47:47 <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
19:47:52 <moneyball> luke-jr: i'd say nothing is off-limits!
19:48:00 <luke-jr> MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea
19:48:12 <MarcoFalke> Just display, not verifying
19:48:12 <jonasschnelli> Probably interested people should form a list of feature requests and/or bugs (gist or wiki)
19:48:13 <instagibbs> stop having commits reported in git commit timestamp order :P
19:48:16 <moneyball> instagibbs: "we" is github
19:48:25 <jonasschnelli> No need to post your feature request here and now
19:48:31 <sipa> yeah
19:48:32 <luke-jr> instagibbs: that's git-log's default too though
19:48:37 <moneyball> yeah i am not intending to create the list right now in this meeting
19:48:48 <jonasschnelli> moneyball: Thanks and great opportunity I agree
19:48:53 <cfields> moneyball: I'd be interested.
19:48:54 <moneyball> i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me
19:48:55 <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.
19:48:58 <gwillen> instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order
19:49:06 <gwillen> there has been an open issue on this for a fucking age
19:49:10 <meshcollider> It is in-person right, not remote attendance?
19:49:52 <gwillen> (for reference https://github.com/isaacs/github/issues/386)
19:49:56 <moneyball> an in-person lunch in SF
19:50:34 <luke-jr> gwillen: --graph would be nice too :p
19:50:44 <gwillen> let's not ask for a pony here ;-)
19:50:47 <wumpus> gwillen: yes please
19:50:51 <sipa> maybe open an issue on our tracker, where people can comment with things to mention?
19:51:01 <sipa> (also, ack topo sort; i've personnally asked them for this years ago)
19:51:02 <MarcoFalke> +1 instagibbs suggestion
19:51:37 <jnewbery> yes please!
19:51:38 <moneyball> sipa: i will do that
19:51:48 <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
19:52:13 <sipa> moneyball: thanks
19:52:15 <moneyball> if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub
19:52:33 <luke-jr> wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient
19:52:39 <moneyball> in the mean time please contribute to the Issue i'll create. i'll post it here once created.
19:52:53 <meshcollider> Sounds good
19:53:04 <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.
19:53:13 <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
19:53:19 <cfields> Things like "display order" they'll hear from everyone.
19:53:35 <ryanofsky> my github feature request would be ability to base prs on top of other prs (just hide commits from base pr)
19:53:37 <luke-jr> wumpus: eg, just the PGP checks
19:53:39 <jnewbery> They should hear it from everyone!
19:53:55 <luke-jr> ryanofsky: ooh, good idea
19:53:56 <meshcollider> I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to
19:53:59 <gmaxwell> luke-jr: that was exactly my thought.
19:54:03 <sipa> cfields: good point
19:54:12 <gmaxwell> (re enforce pgp allowing for access split)
19:54:13 <jonasschnelli> paranoid-mode would probably exclude using github
19:54:15 <cfields> ok, maybe s/paranoia-related/related to the way we use github uniquely/
19:54:19 <sipa> cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns
19:54:30 <cfields> sipa: yes, right.
19:54:31 <wumpus> jonasschnelli:yes, I think that's a very slippery slope :)
19:54:34 <gwillen> cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years
19:54:38 <sipa> any other topics?
19:54:45 <instagibbs> 6 min left
19:54:48 <gmaxwell> gwillen: thre just may be an arch reason as to why its hard.
19:54:49 <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
19:54:49 <wumpus> don't think so
19:54:50 <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"
19:55:26 <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
19:55:34 <ryanofsky> luke-jr, i think that already exists, you can filter based on to address
19:55:36 <wumpus> luke-jr:there is, you acn filter on author@github.com and things like that
19:55:41 <cfields> moneyball: maybe you can provide some context for why they reached out to us specifically?
19:55:57 <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.
19:56:04 <moneyball> jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us
19:56:08 <luke-jr> wumpus: I don't understand
19:56:24 <jonasschnelli> But never forget, they need community feedback to improve to earn money for corporate customers
19:56:32 <jonasschnelli> *from
19:56:33 <ryanofsky> luke-jr, if you want to filter mentions look for Mention <mention@noreply.github.com> in To: header
19:56:34 <gwillen> gmaxwell: I definitely agree on focusing on active problems with no good workaround
19:56:37 <wumpus> luke-jr there's a special to-address they'll add in those cases fornmentions
19:56:42 <cfields> moneyball: heh, gotcha. Thanks.
19:56:47 <luke-jr> hmm
19:57:44 <wumpus> #endmeeting