19:00:55 <wumpus> #startmeeting
19:00:55 <lightningbot> Meeting started Thu Mar 14 19:00:55 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:55 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:55 <achow101> hi
19:01:09 <instagibbs> oh hi
19:01:24 <luke-jr> hi
19:01:27 <dongcarl> oh hi mark
19:01:37 <instagibbs> topic: 0.18 release progress (I'm a bit out of loop on what needs backport etc)
19:01:45 <wumpus> we're pretty much ready to tag 0.18.0rc2
19:01:50 <instagibbs> \o/
19:01:51 <kanzure> hi
19:02:18 <wumpus> any topics?
19:02:22 <cfields> hi
19:02:28 <bitcoin-git> [13bitcoin] 15MarcoFalke opened pull request #15601: build: depends: Switch to python3 (take 3) (06master...061903-buildPy3) 02https://github.com/bitcoin/bitcoin/pull/15601
19:02:33 <meshcollider> hi
19:02:37 <kanzure> mailing list still in flux, no updates really
19:02:38 <jamesob> hi
19:02:43 <sipa> hi
19:02:57 <moneyball> 4 straight weeks no #proposedmeetingtopics :)
19:03:11 <wumpus> thanks moneyball
19:03:16 <wumpus> #topic high priority for review
19:03:30 <instagibbs> I'd like #15557 to get in that list
19:03:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15557 | Enhance `bumpfee` to include inputs when targeting a feerate by instagibbs · Pull Request #15557 · bitcoin/bitcoin · GitHub
19:03:41 <instagibbs> preferably before next fee event ;P
19:03:41 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 three PRs on here #15141 #10973 #14856
19:03:49 <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
19:03:50 <wumpus> instagibbs: ok
19:03:55 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
19:03:57 <gribble> https://github.com/bitcoin/bitcoin/issues/14856 | net: remove more CConnman globals (theuni) by dongcarl · Pull Request #14856 · bitcoin/bitcoin · GitHub
19:04:17 <wumpus> instagibbs: added
19:04:24 <achow101> #15006 for me pls
19:04:28 <gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub
19:04:37 <cfields> I for sure owe review on 14856. Will do today.
19:05:03 <wumpus> cfields: thanks !
19:05:19 <jonasschnelli> hi
19:06:00 <jonasschnelli> Can I add #15512 to the high prio list?
19:06:02 <gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
19:06:12 <jonasschnelli> (if we are fine with adding crypto primitives)
19:06:38 <wumpus> jonasschnelli: yes
19:06:59 <wumpus> at least if there's concept ACK agreement to add it
19:07:33 <jonasschnelli> Okay... added to the list. So waiting for Concept reviews
19:09:03 <wumpus> other topics?
19:09:43 <sipa> instagibbs had a topic
19:09:53 <gmaxwell> RC2 is tagged. hurrah
19:10:20 <instagibbs> any "needs" for 0.18 being the topic, in other words
19:10:28 <wumpus> #topic 0.18.0rc2
19:10:41 <wumpus> it's not tagged yet but intend to do so after the meeting, if no one complains
19:10:53 <gmaxwell> oh. :P
19:11:09 <gmaxwell> Well great, that would be a good time for people to start building too, I guess?
19:11:24 <instagibbs> as an aside I think HWI is near 1.0, 1 open issue right achow101 ?
19:11:41 <sipa> i'm a bit surprised by the amount of people (claiming to) use the reject message on the ML... should we proceed with making it default off in 0.18?
19:11:48 <achow101> instagibbs: yeah, just one thing needs review
19:11:59 <wumpus> #topic reject message default
19:12:13 <wumpus> sipa: I've alwys been divided on removing it to be honest
19:12:28 <sipa> i would very much like to disappear, but my assumption was that it was much less used than people are claiming now
19:12:29 <gmaxwell> The comments on the list have, once you sort through the speculative claims, all been "I use it for debugging"
19:12:45 <wumpus> that makes sense, that's what it's for
19:13:04 <gmaxwell> I'm still confused by those however, -- because is it also "I want to debug a lite wallet without running a full node myself?"
19:13:06 <wumpus> then again disabling it by default wouldn't affect that use case, just make sure it's enabled on the node used for debugging
19:13:12 <gmaxwell> Right.
19:13:14 <instagibbs> right I don't really get it.
19:13:21 <instagibbs> have a full node for debugging?!?
19:13:26 <gmaxwell> I think its unfortunate that that this has come up in the context of removing it entirely.
19:13:33 <achow101> gmaxwell: istm it's debugging user submitted bug reports, not the developer debugging his own app
19:13:49 <sipa> yeah that's the case in the schildbach wallet
19:13:51 <promag> hi
19:14:25 <MarcoFalke> the neutrino wallet is using them as well, apparently
19:14:36 <gmaxwell> achow101: Yes, but capturing the transaction itself would seem to be strictly superior for that.
19:15:00 <gmaxwell> MarcoFalke: along with a bunch of other assumptions about trusting the nodes its communicating with.
19:15:24 <gmaxwell> Which is already a security model we've made a conscious decision to not add support for.
19:15:46 <gmaxwell> MarcoFalke: and clearly not using them with existing nodes, since they require other protocol extensions.
19:15:47 <achow101> gmaxwell: certainly. but at the same time, having the reject message can provide better ux as the user can see why their transaction was rejected (in theory)
19:15:48 <MarcoFalke> They way one wallet makes it trustworthy is to send the tx to all nodes and see if at least half of them report the same reject reason
19:16:00 <gmaxwell> MarcoFalke: that doesn't make it trustworthy.
19:16:23 <MarcoFalke> Yeah, I am not going to start to explain what is wrong with that, even
19:16:31 <gmaxwell> Right...
19:16:41 <sipa> i'm just bringing it up because i think this ML discussion should have happened before making it disabled by default, rather than before removing it entirely
19:16:56 <MarcoFalke> sipa: You are right
19:17:16 <MarcoFalke> It is sort of pointless to make them disabled by default, but then not remove them
19:17:23 <moneyball> agree with sipa
19:17:57 <MarcoFalke> So they should probably be enabled by default again for now. Not sure if that makes it into 0.18.0
19:18:01 <jnewbery> it's not too late to revert #13134
19:18:03 <gribble> https://github.com/bitcoin/bitcoin/issues/13134 | net: Add option `-enablebip61` to configure sending of BIP61 notifications by laanwj · Pull Request #13134 · bitcoin/bitcoin · GitHub
19:18:08 <jnewbery> or just change the default to 0
19:18:13 <gmaxwell> It was covered in the optech newsletter, but I don't see a prior ML discussion of it.
19:18:25 <MarcoFalke> yeah, just change the default
19:18:31 <MarcoFalke> No need to remove the option
19:18:32 <gmaxwell> MarcoFalke: it's not pointless to disable them by default but not remove them.
19:18:43 <gmaxwell> MarcoFalke: they're a source of a non-trivial amount of junk protocol chatter.
19:18:53 <gmaxwell> MarcoFalke: and the reliance on them creates its own problems.
19:19:00 <jnewbery> sorry, I mean revert #14054
19:19:02 <gribble> https://github.com/bitcoin/bitcoin/issues/14054 | p2p: Disable BIP 61 by default by MarcoFalke · Pull Request #14054 · bitcoin/bitcoin · GitHub
19:19:02 <gmaxwell> (including incentives to sybil attack the network)
19:20:06 <MarcoFalke> In light of the spv wallets that use them, default by off is the same as having them removed
19:20:07 <sipa> ideally we can convince people to switch to more reliable methods before disabling support for it
19:20:12 <gmaxwell> I don't see anything terrible about delaying disabling it. But I am also not sure what is going to change.
19:20:18 <gmaxwell> sipa: there isn't anything to switch.
19:20:40 <gmaxwell> sipa: the two respondands saying they're using it (1) only log it, (2) don't work against bitcoin core already.
19:20:52 <sipa> gmaxwell: ?
19:21:32 <gmaxwell> sipa: android wallet doesn't actually do anything with the messages but log them, the neutrino wallet requires protocol extensions that are only in btcd.
19:21:44 <sipa> right, for now
19:21:55 <gmaxwell> so whats there to switch?
19:22:02 <sipa> ou suggested logging the tx itself instead of the reject message, for example
19:22:12 <gmaxwell> Okay, fair point!
19:22:27 <sipa> plus there are other methods like seeing transactions announced back to yourself (okay, not very reliable either)
19:22:54 <sipa> i just wish this discussion was more resolved before we possibly anger people needlessly by ripping something out they stubbornly rely on now
19:23:11 <gmaxwell> sipa: one client does that but sends their txn to all peers :) ...
19:23:20 <gmaxwell> 12:20:11 < gmaxwell> I don't see anything terrible about delaying disabling it. But I am also not sure what is going to change.
19:23:30 <jnewbery> sounds like the action item is to revert #14054 before 0.18
19:23:32 <gribble> https://github.com/bitcoin/bitcoin/issues/14054 | p2p: Disable BIP 61 by default by MarcoFalke · Pull Request #14054 · bitcoin/bitcoin · GitHub
19:23:35 <sipa> yeah, it's a fair point that delaying may just literally mean delaying it
19:23:47 <sipa> but perhaps it does resolve the discussion further
19:24:03 <gmaxwell> I think we should probably make it clear that we still intend to disable it by default.
19:24:20 <MarcoFalke> jnewbery: I am fine with that, but I hope that doesn't give a signal that they are encouraged
19:24:27 <MarcoFalke> They should still go in the long term
19:24:32 <sipa> agree
19:24:40 <gmaxwell> I mean I think it was clear years ago that these shouldn't be used the way people are advocating using them... like on day one.
19:24:54 <sipa> i doubt that was clear to everyone :)
19:25:01 <cfields> Hasn't our unwritten policy always been to deprecate in one release, and non-default/remove in the next?
19:25:30 <MarcoFalke> cfields: I tried to do that, but apparently people only picked up on this when I wanted to remove them
19:25:35 <sipa> cfields: for RPC that works... for P2P services it's harder
19:25:48 <jnewbery> That's easier for RPCs because deprecation is immediately obvious to the user
19:25:50 <gmaxwell> some of the things people are reporting doing with them haven't worked right for a long time (or ever)... (like trying to differentiate between already spent and other causes of invalidity)
19:26:05 <moneyball> It would also help to better educate what they should do as an alternative. My reading of the thread still has me uncertain, and they also do not seem to know what to do.
19:26:21 <gmaxwell> Actually disabling it in a release has that effect somewhat, as it'll be years before it's gone completely on the network.
19:26:26 <cfields> sipa: I just meant that if it's going to be non-defaulted in one version, seems only fair to put it through a deprecation cycle in the preceding one.
19:26:48 <jnewbery> how do you deprecate a P2P message in a way that users notice?
19:26:50 <moneyball> Good next steps IMO would be 1) revert in v0.18 2) communicate this to the list but also emphasize the long-term plan 3) educate on alternatives for these users
19:26:51 <sipa> cfields: right, but what does 'deprecation' mean here? if it's not disabled by default, it's not even observable
19:26:56 <gwillen> cfields: but I think sipa's point is that deprecation doesn't notify the people who care
19:27:07 <gmaxwell> moneyball: to some extent what wants to be done just can't be done, even with rejects. You can't find out if the network is taking your transaction, it's just not something anyone can tell.
19:27:19 <cfields> Just in the release notes.. we intend to flip this to disabled-by-default in the next release.
19:27:28 <sipa> cfields: sgtm
19:27:37 <cfields> that's all I meant by "deprecate".
19:27:40 <gmaxwell> cfields: ack.
19:27:42 <wumpus> so I guess this does hold up rc2 tagging then
19:27:59 <jnewbery> I'm happy to open that PR now, unless MarcoFalke wants it
19:28:06 <MarcoFalke> jnewbery: go for it
19:28:07 <gmaxwell> jnewbery: go do it.
19:28:22 <jnewbery> I'll do it today
19:28:28 <provoostenator> You can make it noticable by always returning reject :-)
19:28:37 <gmaxwell> lol
19:28:46 <gmaxwell> provoostenator: nope, in fact.
19:28:53 <sipa> reject 00 "The operation completed succesfully"
19:29:02 <gmaxwell> provoostenator: because reject isn't doing anything in existing software except ending up burried in some logs.
19:29:20 <gmaxwell> so even that would be hit or miss.
19:30:21 <sipa> https://www.medo64.com/content/media/errortheoperationcompletedsuccessfully.png
19:31:19 <achow101> what's the long term plan for removal? default disable in 0.19, remove in 0.20?
19:31:24 <gwillen> I think starting mailing list discussion of what the alternatives are, and getting moneyball to spread it in the newsletter, is probably the best way to spread the good word :-)
19:31:32 <MarcoFalke> achow101: Something like that
19:31:56 <MarcoFalke> [15:26] <moneyball> Good next steps IMO would be 1) revert in v0.18 2) communicate this to the list but also emphasize the long-term plan 3) educate on alternatives for these users
19:32:08 <gmaxwell> gwillen: right, what I would recommend for these logging cases is that they log the transaction and current block height.
19:32:40 <MarcoFalke> gmaxwell: you mean the full tx in hex?
19:32:56 <sipa> base85 FTW
19:32:57 <moneyball> fyi harding referred to the PR commit in the sep 18 newsletter https://bitcoinops.org/en/newsletters/2018/09/18/
19:33:04 <cfields> MarcoFalke: where do I point my DoS? :)
19:33:10 <moneyball> and the discussion that marco started in the mar 12 newsletter https://bitcoinops.org/en/newsletters/2019/03/12/
19:33:16 <gmaxwell> MarcoFalke: whatever is required for them to be able to reproduce! in some applications it might be less than the full tx.
19:33:26 <gmaxwell> cfields: you're misunderstanding, the wallet should log its own transaction.
19:33:37 <MarcoFalke> Yeah, its only the own wallets txs
19:33:42 <cfields> gmaxwell: I was, thanks.
19:33:54 <gmaxwell> MarcoFalke: e.g. if the wallet always stores the tx like bitcoin core, the current block and txid are enough.
19:34:45 <gmaxwell> cfields: basically the debugging case is "User says my transaction was never confirming" ... what do you do?  Andreas is pointing out that reject messages have been helpful.
19:35:31 <gmaxwell> Another thing is that I see no feefilter support in that software... so obviously processing feefilters would allow them to locally learn about some of the failure cases they care about.
19:36:51 <gmaxwell> right now reject basically only tells you didn't meet minfee vs "something else happened at the first hop", feefilter + listen to hear it back gets you essentially that, but more reliable.
19:37:15 <sipa> gmaxwell: though feefilter can't be relied upon either in an adverserial setting
19:37:26 <sipa> it is less DoS risk though
19:37:29 <gmaxwell> sipa: no but it's probably better than reject messages.
19:38:23 <gmaxwell> esp if you obey it, e.g. don't send a txn that would violate the filter to a particular peer.
19:40:03 <sipa> end topic?
19:40:17 <gmaxwell> ack
19:40:18 <wumpus> other topics?
19:40:57 <wumpus> #endmeeting