19:00:15 <wumpus> #startmeeting
19:00:15 <lightningbot> Meeting started Thu Jan 11 19:00:15 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:15 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:21 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
19:00:38 <meshcollider> hi
19:00:40 <wumpus> congrats everyone on merging segwit wallet!
19:00:47 <meshcollider> \o/
19:00:48 <achow101> hi
19:01:04 <wumpus> I think we should focus this meeting on what there is to do still for 0.16
19:01:21 <provoostenator> hi
19:01:22 <wumpus> I've just updated https://github.com/bitcoin/bitcoin/milestone/30 removing everything that isn't either a bugfix or has to do with segwit
19:01:25 <instagibbs> hi
19:01:31 <instagibbs> \o/ so great to see
19:01:32 <wumpus> (well, moving it forward to 0.17)
19:02:18 <provoostenator> I'd like to get either #11991 or #11937 in so non-tech-savy people can actually use bech32.
19:02:21 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
19:02:23 <wumpus> so that is the "high priority" list for now, if there's anything that should be added let me know
19:02:23 <gribble> https://github.com/bitcoin/bitcoin/issues/11937 | Qt: Setting for deciding address type (legacy, p2sh or bech32) by hsjoberg · Pull Request #11937 · bitcoin/bitcoin · GitHub
19:02:27 <BlueMatt> #11281 needs rebase and resolution of current discussion
19:02:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
19:02:40 <jonasschnelli> Will do soon
19:02:46 <wumpus> provoostenator: agreed
19:02:59 <provoostenator> I'll try to keep them fresh based on feedback.
19:03:05 <instagibbs> -qt support for address types i think is a big ? still
19:03:08 <jonasschnelli> Yes. I also think 11991 11937 should go into 0.16
19:03:13 <BlueMatt> I believe there's still pending segwit wallet stuff in some rpcs that are still TODO
19:03:14 <BlueMatt> sipa?
19:03:15 <achow101> If 11281 goes in, I would like to also have #11200
19:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11200 | Allow for aborting rescans and canceling showProgress dialogs by achow101 · Pull Request #11200 · bitcoin/bitcoin · GitHub
19:03:36 <cfields> hi, here
19:04:05 <achow101> also #12101 and #12104 are bugfix-ish
19:04:06 <provoostenator> bech32 change behavior is nice to have; #11991 is mostly for my own OCD and I can just run that myself
19:04:07 <gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
19:04:08 <gribble> https://github.com/bitcoin/bitcoin/issues/12104 | HTTP Error 404: Not Found
19:04:09 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
19:04:32 <achow101> s/12024/12104
19:04:33 <BlueMatt> do we want to fix the non-regression rpc too-many-sockets thing given its an upstream bug? cfields?
19:04:37 <provoostenator> (sorry, I meant #12119)
19:04:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
19:05:06 <cfields> BlueMatt: yes, I'll clean that up and PR it today. What's not clear, though, is if we should attempt to max out available fds.
19:05:08 <wumpus> 11200 seems more like a feature and isn't necessarily segwit related
19:05:25 <wumpus> more for 0.17
19:06:20 <provoostenator> wumpus: when you move something to 0.17 does that mean it be merged before 0.16 is branched off, or does it not have that meaning?
19:06:30 <provoostenator> *it won't
19:06:45 <wumpus> provoostenator: yes
19:07:28 <BlueMatt> wumpus: tend to agree re: 11200, though I'd still very much like to see #11281
19:07:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
19:07:34 <meshcollider> Will we have the signing certificates ready for the release? jonasschnelli cfields
19:07:49 <cfields> wumpus: consider the maxing fd's question a topic suggestion. I'm unsure what to do there.
19:07:58 <wumpus> BlueMatt: isn't that one already on there?
19:08:16 <jonasschnelli> meshcollider: at least there is a static non distributed RSA cert now available... (OSX).
19:08:32 <BlueMatt> wumpus: it is, was just re-enforcing :)
19:08:35 <meshcollider> jonasschnelli: ok
19:08:47 <jonasschnelli> (but no clue about Windows) topic?
19:08:52 <cfields> meshcollider: yes, we didn't get the threshold key setup in time, so we have a temporary key now. Presumably for 0.16 only.
19:09:17 <wumpus> BlueMatt: but yes I agree keeping that, it's more of a fix I guess (but also not really)
19:09:38 <promag> o/
19:10:08 <cfields> meshcollider: I've written up a few little things worth committing, I'll PR those today as well.
19:10:09 <wumpus> great news regarding the signing key
19:10:15 <wumpus> cfields: ok, topic noted
19:11:22 <cfields> oh, on to me then?
19:11:45 <cfields> #11785 is what I'm unsure about
19:11:46 <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Raise the open fd limit to the maximum allowed by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
19:11:48 <wumpus> #topic maxing out fds
19:12:15 <wumpus> oops, accidentelly tagged #12101 0.17 while it should be 0.16
19:12:16 <provoostenator> As discussed earlier today: what's the minimum time before we branch of 0.16? So there's some time to test stuff and fix PR's.
19:12:17 <gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
19:12:27 <cfields> tl;dr: there was an issue where fd's could be maxed out causing crashes and weird behavior. Let's assume that we get that issue under control. Should we still attempt to bump up our fd limit?
19:13:12 <wumpus> cfields: I'm not sure that should be default behavior, how much is it frowned upon if daemons do that, don't know how other software handles it?
19:13:33 <wumpus> cfields: I think the usual way is to leave ulimit setting to the user/sysadmin
19:13:49 <ryanofsky> provoostenator, i think normally there is a feature freeze on master before creating the release branch
19:14:16 <wumpus> yes, normally there's a feature freeze
19:14:34 <wumpus> I also need to open translations for 0.16
19:14:35 <cfields> wumpus: I tend to agree with that. IMO if we're bumping into fd issues, we want to see them rather than mask them
19:14:58 <cfields> but iirc gmaxwell was generally in favor of a general bump
19:15:02 <wumpus> cfields: indeed, we should try to be robust against them, or at least exit with a clear error if that it's not possible
19:15:33 <cfields> wumpus: ok, mind commenting there? I'll poke gmaxwell again about it too
19:15:45 <cfields> </topic>
19:15:51 <wumpus> cfields: sure
19:15:59 <cfields> thanks :)
19:16:01 <wumpus> other topics?
19:16:04 <jonasschnelli> I have a short disussion request for 11281
19:16:07 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
19:16:16 <jonasschnelli> Is that a concern (see commit above)=
19:16:17 <jonasschnelli> ?
19:16:35 <jtimon> wumpus what are these "fds" to max out?
19:16:40 <wumpus> #topic "Avoid permanent cs_main/cs_wallet lock during RescanFromTime" discussion (jonasschnelli)
19:16:44 <jonasschnelli> sipa brought up the point, but I think it's okay if we just mention that in the rpc help
19:16:45 <wumpus> jtimon: "file descriptors"
19:16:49 <jtimon> thanks
19:17:23 <jonasschnelli> background: you may import a key and can see it's there but the related transactions are (still) missing
19:17:33 <achow101> I think it's fine to mention that in the help
19:17:34 <jonasschnelli> since the lock is released now
19:17:41 * BlueMatt is fine with the documentation fix, we cant always block the world waiting on things to be consistent
19:17:52 <BlueMatt> but sipa is the one who brought it up and apparently is mia today
19:18:05 <jonasschnelli> Okay. Lets wait on his feedback
19:18:08 <achow101> the alternative would be to block those calls during a rescan, right?
19:18:09 <jonasschnelli> </topic>
19:18:17 <wumpus> other topics?
19:18:20 <promag> what happens today if you import and then it crashes?
19:18:24 <jnewbery> Other PRs that would be nice for 0.16 are the RPC changes in #7965 (#10583, #11415, #10579)
19:18:26 <gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
19:18:29 <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
19:18:32 <gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
19:18:33 <jonasschnelli> promag: I guess the same problem
19:18:35 <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
19:18:47 <kanzure> hi.
19:18:48 <wumpus> jnewbery: those have nothing to do with segwit, so I moved them to 0.17
19:19:02 <jonasschnelli> Agree
19:19:19 <jnewbery> Shame. They deprecate the RPCs but don't remove them, so we're stuck with those wallet dependencies until v0.18
19:19:46 <wumpus> if we do a "theme release" at all we need to focus, sorry
19:19:48 <promag> jonasschnelli: should we "mark" those addresses until the rescan finishes?
19:19:51 <ryanofsky> 11415 maybe could be merged now
19:19:58 <jtimon> do #8994 and #10757 have a chance to get merged for 0.16 if I fix the nits?
19:20:00 <promag> jonasschnelli: future work I guess
19:20:01 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
19:20:05 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
19:20:13 <jonasschnelli> promag: Yes... probably... need to think about that first
19:20:19 <wumpus> no, we're not adding non-segwit features for 0.16
19:20:29 <BlueMatt> wumpus: oooo, "theme release", can we start themeing based on cocktails like openwrt?
19:20:41 <achow101> presumably 0.17 will be sooner than the usual 6 months?
19:20:48 <ryanofsky> ok so feature freeze has already started?
19:20:51 <wumpus> BlueMatt: lol!
19:21:02 <instagibbs> ryanofsky, non-segwit ff i believe so
19:21:04 <jonasschnelli> I think since merging SW wallet freeze is active
19:21:06 <wumpus> ryanofsky: for non-segwit things, yes, for segwit things it's open for sicussion
19:21:07 <cfields> BlueMatt: by that you mean "white russian" (or something) for ~5 years, iirc?
19:21:07 <instagibbs> qt stuff might still be required
19:21:08 <BlueMatt> yes, didnt we say feature freeze when segwit wallet got merged
19:21:10 <achow101> ryanofsky: I'm guessing feature freeze started last night as soon as 11403 merged
19:21:22 <wumpus> BlueMatt: yes
19:21:22 <BlueMatt> cfields: yea......
19:21:31 <jtimon> achow101: really? I thought 0.16 was the exception and we're getting close to its regular planned non ahead of time date
19:21:39 <jonasschnelli> no
19:21:42 <promag> btw, 17 theme is?
19:21:53 <wumpus> achow101: we could do 0.17 sooner, but one thing at a time please, this is for discussion once 0.16 is out of the door :)
19:21:57 <BlueMatt> promag: white russian, apparently
19:22:13 <wumpus> no theme for 0.17, no themes again please, back to simply time based releases
19:22:24 <meshcollider> wumpus: you mean 17.0 ;)
19:22:34 <provoostenator> Given that the world demands SegWit from the Core wallet, I tend to agree about feature freeze for non-SegWit stuff.
19:22:43 <jtimon> BlueMatt: it seems tohe feature freeze is being done sooner than that
19:22:49 <provoostenator> And I guess it's about hte regular time to release anyway?
19:22:52 <wumpus> segwit was an exception because that was 'promised' for 0.15.1, I don't think this should become routine
19:23:27 <achow101> provoostenator: I think there's still 2 months left for the usual timing
19:23:51 <wumpus> yes, we're intentionally trying to do the release sooner than the usual planning
19:24:12 <wumpus> (e.g. the one in #11449 is worst-case)
19:24:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
19:24:30 <MarcoFalke> Is #10387 a blocker for 0.16?
19:24:33 <gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
19:24:50 <jonasschnelli> MarcoFalke: no... can go into 0.17 IMO
19:24:53 <wumpus> MarcoFalke: I don't know, let's discuss
19:24:54 <jonasschnelli> Or why would it be?
19:24:59 <jtimon> I thought the only blocker for 0.16 was #11403 ?
19:25:03 <BlueMatt> its pending on gmaxwell, just need his ack, I think
19:25:05 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
19:25:34 <BlueMatt> but, its def a "feature"
19:25:38 <jonasschnelli> 10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that
19:25:39 <BlueMatt> we're doing the bit announce on master already
19:25:46 <wumpus> ok moving it to 0.17
19:25:48 <BlueMatt> so thats ok for it to go 17
19:26:14 <jonasschnelli> Ah,.. did 10387 still had the 0.16 tag?, Yes. Needs a 0.17 then
19:26:35 <wumpus> that leaves 13 open things in https://github.com/bitcoin/bitcoin/milestone/30
19:26:51 <wumpus> (including the release notes and the release schedule itself)
19:27:25 <sipa> oops, i'm here
19:27:33 <BlueMatt> lol
19:27:35 <sipa> timezone confusion
19:28:02 <BlueMatt> sipa: plx comment on 11281
19:28:02 <jonasschnelli> we need a core meeting alarm/notification service
19:28:12 <BlueMatt> also pending segwit wallet work
19:28:16 <BlueMatt> whats still missing?
19:28:18 <meshcollider> Does anything actually need to be done for #11048
19:28:19 <gribble> https://github.com/bitcoin/bitcoin/issues/11048 | Weird gettransaction details on testnet with segwit · Issue #11048 · bitcoin/bitcoin · GitHub
19:28:20 <jonasschnelli> sipa, Bluemat refers to https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
19:28:40 <provoostenator> How do I add myself to the fancy meeting username mention ping?
19:28:55 <instagibbs> gotta tip wumpus some bch
19:29:23 <achow101> lol
19:29:23 <meshcollider> instagibbs: lol
19:29:25 <sipa> yeah will do, on my phone in a bar now
19:29:36 <instagibbs> RWC?
19:29:40 <wumpus> instagibbs: please no, no need to threaten me, will add him :)
19:29:51 <sipa> instagibbs: yes
19:30:18 <BlueMatt> sipa: woke up in a bar?
19:30:42 <sipa> BlueMatt: just charged my phone  and saw your signal msg
19:30:43 <jonasschnelli> heh
19:31:22 <cfields> so apparrently BlueMatt is the core meeting alarm service
19:31:26 <instagibbs> provoostenator, what's the status of -qt PR for 0.16? I'm kind of out of it but am willing to test with my branch
19:32:05 <wumpus> any other topics?
19:32:19 <luke-jr> hi
19:32:27 <provoostenator> instagibbs: #11991
19:32:27 <bitcoin-git> [13bitcoin] 15kekimusmaximus opened pull request #12158: Avoid unnecessary copy of objects. (06master...06avoid_copies) 02https://github.com/bitcoin/bitcoin/pull/12158
19:32:30 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
19:32:37 <BlueMatt> lol, ok, everyone's here, start over now?
19:32:39 <luke-jr> #12146 should be tagged 0.16 too
19:32:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12146 | Wallet: Support disabling implicit Segwit operation by luke-jr · Pull Request #12146 · bitcoin/bitcoin · GitHub
19:32:56 <provoostenator> Bit of discussion about the UI... but otherwise ready to go.
19:33:03 <gmaxwell> ^ 11991 seems like an obvious and easy win.
19:33:16 <sipa> #11991
19:33:19 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
19:33:44 <luke-jr> indeed, I'd also suggest the bech32 change thing
19:34:20 <gmaxwell> yes, the "use native change if destinations are native"?  I think that makes a lot of sense.
19:34:24 <luke-jr> #12119
19:34:26 <gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
19:34:41 <provoostenator> bech32 change thing needs a small refactor which I'll try to do tomorrow. But also has some discussion about which circumstances should trigger bech32 use. Please weigh in...
19:34:48 <wumpus> both 11991 and 12119 are already in the 0.16 milestone
19:34:53 <gmaxwell> The whole reason we didn't _always_ use native change was privacy, but if the outputs are native, then that same argument says we should use native.
19:35:08 <provoostenator> What about inputs?
19:35:17 <sipa> arguably you could just uniformly ranomly pick the address type of 1 of the inputs, and make the change that
19:35:26 <gmaxwell> provoostenator: I think they're irrelevant.
19:35:41 <wumpus> sipa: sounds like a plan
19:35:47 <gmaxwell> sipa: I don't think that makes any sense.
19:35:53 <provoostenator> As in: if any input or any output is bech32, use bech32, unless changeaddress param says otherwise. .... ok, why intput irrelevant?
19:35:54 <luke-jr> wumpus: 12146 isn't yet.
19:36:04 * sipa meh 12146
19:36:09 <wumpus> luke-jr: seems like that needs some more discussion
19:36:09 <gmaxwell> Why would it possibly be relevant in any way?
19:36:13 <instagibbs> we want to frustrate chain analysis, mimicking the payment as much as possible is ++
19:36:19 <promag> gmaxwell: what if someone wants 0.16 to behave like 0.15?
19:36:39 <luke-jr> wumpus: releasing Segwit wallet without it is a problem for people who don't want to use Segwit.
19:36:43 <provoostenator> We also want to reduce fees.
19:36:50 <gmaxwell> The only reason to not always use native, assuming you are using segwit to begin with in your wallet, is that it would make it easier to tell which of the outputs are change.
19:36:56 <jonasschnelli> luke-jr: define don't use?
19:37:16 <wumpus> luke-jr: just don't use the segwit address types then?
19:37:17 <gmaxwell> But that doesn't apply if the outputs (any of them, arguably) are native.
19:37:20 <luke-jr> jonasschnelli: never have a Segwit UTXO despite what anyone else may do
19:37:25 <provoostenator> So in other words, if you're spending from a bech32 address, there's no reason _not_ to use a native address as change?
19:37:39 <luke-jr> wumpus: without 12146, people can malleate your address and you'll never know
19:37:39 <gmaxwell> provoostenator: no!
19:37:42 <instagibbs> provoostenator, ??
19:37:52 <wumpus> is address malleation a thing now?
19:37:59 <provoostenator> It saves fees and there's no privacy downside, what am I missing?
19:38:07 <sipa> luke-jr: they can already
19:38:11 <gmaxwell> Again, inputs are irrelevant-- I can't figure out why you think inputs are at all relevant.
19:38:12 <jonasschnelli> provoostenator: he's worried about block size increase
19:38:17 <sipa> and have forever
19:38:24 <jonasschnelli> as sipa said,.. it was also possible by p2pk -> p2pkh
19:38:27 <luke-jr> sipa: with 12146, you would at least notice / not accept it
19:38:36 <sipa> luke-jr: why not? it's cheaper!
19:38:38 <jonasschnelli> s/was/is
19:38:48 <luke-jr> sipa: what?
19:39:03 <wumpus> would anyone use that at all, why would it be worth maintaining?
19:39:12 <sipa> you're lucky if someone sends you a witness output instead anyone of p2pkh
19:39:13 <jonasschnelli> I think luke-jr argument are more political/philosophical then technical/economical
19:39:20 <wumpus> it just complicates all kinds of logic
19:39:29 <gmaxwell> provoostenator: the privacy downside arises when your pay to a non-segwit destination.  If you pay a non-segwit destination but make a native output as change, then which of the outputs is change is far more easily identified.
19:39:30 <luke-jr> wumpus: because using Segwit enables miners to increase block size, and has no benefits for the current wallet.
19:39:37 <instagibbs> i think this is going to be another "no one else agrees" type argument, sorry luke-jr
19:39:39 <sipa> (i think it's really bad that we accept outputs to addresses we didn'√ give out)
19:39:41 <BlueMatt> provoostenator: its still a privacy leak, you're (probably) much, much more likely to use non-bech32 outputs as non-change, so irrespective of the inputs you'd be pretty clearly tagging your change output
19:40:06 <sipa> but it's not specific to segwit, and needs fixing independently
19:40:07 <instagibbs> simply not handing out those addresses should be enough... sender doesn't care if you want to spend more later
19:40:10 <BlueMatt> provoostenator: in fact, even worse, you're tagging it *because* your inputs are bech32 you're making clear that you support segwit in your wallet, so the bech32 output is *most likely* the change
19:40:27 <luke-jr> instagibbs: the sender can trick you into accepting Segwit without 12146
19:40:27 <wumpus> instagibbs: indeed
19:40:35 <instagibbs> luke-jr, worse, the sender *wont know* you don't implictly convert, leading to a orphaned utxo!
19:40:36 <wumpus> 'trick you into accepting segwit'
19:40:48 <instagibbs> whatever jerk is doing that
19:40:48 <gmaxwell> But if the other outputs are native, then this issue doesn't exist.
19:41:00 <luke-jr> instagibbs: orphaned UTXO is exactly the expected outcome
19:41:04 <luke-jr> instagibbs: and that's his fault
19:41:06 <Chris_St1> so the debate is whether we are creating the change output as the same script type as the payment output in a two output scenario?
19:41:07 <instagibbs> .....
19:41:11 <wumpus> man, that sounds like it should be prosecuted as a war crime
19:41:32 <provoostenator> Alright, so rule should be: ignore inputs, if any output is bech32, use bech32 for change, unless setting overrides?
19:41:36 <luke-jr> Chris_St1: there's two parallel conversations going on here now :/
19:41:49 <provoostenator> luke-jr: yes, IRC needs threads
19:42:09 <wumpus> #topic when to use bech32 for change
19:42:11 <wumpus> ^^
19:42:13 <meshcollider> provoostenator: yes that's most sensible
19:42:16 <BlueMatt> provoostenator: thats not a bad idea, imo
19:42:17 <Chris_St1> what about when there are more than two outputs? Or are we just worried about GUI?
19:42:19 * jtimon thinks about what "trick you into accepting segwit" may mean...
19:42:31 <instagibbs> Chris_St1, privacy mostly
19:42:37 <gmaxwell> provoostenator: thats my belief.
19:42:41 <meshcollider> Was sipa suggestion of random choice serious or a joke
19:42:44 <provoostenator> Chris_St1: _any_ output, not _all_
19:42:49 <instagibbs> meshcollider, serious to me, makes sense
19:43:00 <luke-jr> IMO any output makes sense.
19:43:01 <gmaxwell> provoostenator: I think someone could reasonable argue that it should be "if a majority" rather than any.
19:43:03 <cfields> don't you lose the change privacy if there's a mix of segwit output types, though?
19:43:04 <meshcollider> Yeah was unsure if there's any downside
19:43:09 <wumpus> meshcollider: I think he was serious, it makes sense, less deterministic the change choice the better
19:43:33 <Chris_St1> instagibbs: yes, but what if you a 3 segwit payment outputs and 2 p2pkh payment outputs, what is the change type?
19:43:37 <gmaxwell> I think "all" is obviously too strong.
19:43:37 <cfields> if there's a p2wsh output and change goes to p2wpkh, that's obvious
19:43:53 <instagibbs> Chris_St1, arguments to be had. Could flip weighted coin, could just pick the cheapest to mimic
19:44:00 <instagibbs> (native)
19:44:03 <gmaxwell> cfields: "segwit" here means native.
19:44:04 <morcos> I don't think its worth going overboard with complication.   If you are super privacy conscious you can manually do what you want, otherwise we should make the default what makes sense for the network.
19:44:11 <morcos> So I like provoostenator's idea
19:44:24 <provoostenator> Chris_St1: bech32 in my proposal s well as the majority proposol (which I think it's a bit complicated...)
19:44:28 <Chris_St1> morcos: But that erodes the privacy of *everyone*. see zcash?
19:44:59 <morcos> Chris_St1: i don't think that analogy applies
19:45:03 <gmaxwell> Any is what I proposed on the PR, though I noted that "majority" would also be defensible.  Requiring all, or worse, not using native even if all are native is bad for privacy.
19:45:07 <BlueMatt> yea, majority-are-native or signle-is-native are both fine with me
19:45:13 <luke-jr> weighed random?
19:45:31 <gmaxwell> I think it's okay to bias some here towards the more cost effective form.
19:45:36 <morcos> well maybe, but thats why we're preservign some level of privacy...  in that we only use bech32 for change if we're paying at least one bech32 address
19:45:37 <wumpus> yes
19:45:38 <instagibbs> hiding with other segwit wallets imo is your best bet anyways...
19:45:49 <gmaxwell> also the difference between these things only matters for sendmany...
19:45:52 <provoostenator> luke-jr: I that would be a great way for me to demonstrate my C++ incompetence :-)
19:46:07 * sipa is fine with (if not otherwise configured) using any bech32 -> change is bech32
19:46:25 <jnewbery> any-output-is-native seems reasonable to me
19:46:41 <achow101> same
19:46:42 <gmaxwell> sipa: I think my suggestion was "unless configured that change should be legacy, change is native if any output is native".
19:46:57 <morcos> i think non-determinism in what kind of change address you have is just ick..  especially since the p2sh-wrapped kind is temporary
19:47:00 <provoostenator> As for luke-jr's point: having some flag to completely opt-out of SegWit seems reasonable to me.
19:47:04 <gmaxwell> (or if anyone felt that was too strong, change is native unless the majority is non-native; but it seems no one does)
19:47:05 <sipa> gmaxwell: and p2sh-p2wsh otherwise?
19:47:13 <gmaxwell> sipa: yes.
19:47:20 <sipa> makes snese
19:47:35 <Chris_Stewart_5> gmaxwell: by native you mean p2wpkh?
19:47:41 <gmaxwell> sipa: so if you set yourself to be legacy, you'll stay legacy regardless, in order to respect any weird requirement to avoid creating segwit outputs.
19:48:08 <instagibbs> morcos, if it has native change is native is entirely determinstic, luckily
19:48:21 <instagibbs> sorry, has native, comma, change is native
19:48:52 <gmaxwell> morcos: I think you were responding to things like "weighed random change types"
19:49:03 <morcos> correct
19:49:06 <BlueMatt> more topics?
19:49:24 <luke-jr> back to 12146?
19:49:26 <gmaxwell> yea, I could go for weighed-random change types if the choice were otherwise neutral, but it's not.
19:49:31 * BlueMatt notes that it really would be nice to see #12118 in 0.16, just because its really a free 5% speedup in removeForBlock which is a big chunk of block validation latency....
19:49:33 <gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
19:49:45 <instagibbs> luke-jr, Creating utxo bloat to *slightly* reduce blocksize is weird weird feature to add imo
19:49:51 <instagibbs> (if we've transitioned)
19:49:57 <luke-jr> instagibbs: it's not UTXO bloat.
19:50:10 <BlueMatt> luke-jr: nack, just use 0.15.1 and focus on the real fix of splitting hd chain
19:50:11 <instagibbs> the scenario here is that some joker pays you, and you don't want to spend it, right?
19:50:25 <morcos> +1 BlueMatt
19:50:30 <BlueMatt> alternatively, this could be accomplished by using labels/accounts
19:50:40 <BlueMatt> label addresses and then payments will show up without the labels
19:50:44 <luke-jr> instagibbs: more or less
19:50:57 <luke-jr> BlueMatt: NACK, to myself and many others, mandatory Segwit wallet is a regression
19:51:06 <BlueMatt> then dont use 0.16
19:51:15 <luke-jr> so 0.15 is supported forever?
19:51:19 <gmaxwell> luke's argument is lame but there are other arguments for the position...  But I think it's ultimately futile.
19:51:21 <luke-jr> including new features?
19:51:31 <morcos> luke-jr: right, but thats basically the only feature, so just dont use it until we have the version that doesn't accept all variations of key encoding
19:51:32 <BlueMatt> if you want the option, do the real fix, not the dirty hack of working like 0.15.1
19:51:33 <gmaxwell> luke-jr: by anyone who cares to support it
19:51:36 <instagibbs> This feature doesn't make any sense to me though.
19:51:55 <luke-jr> BlueMatt: there isn't a better fix
19:51:56 <BlueMatt> (the real fix being splitting the hd chain so that we never identify as ours addresses other than the ones we gave out)
19:52:07 <morcos> ^ it's in sipas gist
19:52:11 <achow101> luke-jr: the real fix is using different hd paths
19:52:13 <sipa> indeed.
19:52:14 <BlueMatt> which sipa proposed (I believe to much agreement) as the long-term route for the wallet
19:52:15 <luke-jr> BlueMatt: that's more than a fix. :p
19:52:17 <gmaxwell> instagibbs: it's very bad that we support showing funds paid to addresses we never issued.  It invites really bad behavior that can cause irrecoverable funds loss.   But the ship has already sailed on that.
19:52:23 <instagibbs> gmaxwell, no I get the issue
19:52:30 <instagibbs> I don't get his fix, it's one-sided
19:52:39 <gmaxwell> ah.
19:52:56 <morcos> we all agree to fixing that, what we don't care about is that we are temporarily makign it worse for the case of giving out legacy and receiving segwit
19:52:57 <instagibbs> sender has no clue you won't accept it!(outside of us wagging fingers to not try it)
19:53:02 <gmaxwell> Well thats because his motivation isn't one of the sensible ones, it's because he's discouraging people from using segwit to keep the blocksize down.
19:53:10 <BlueMatt> luke-jr: it is more than a fix for your specific issue, but its much nicer and isnt ridiculous from a ux/maintainability perspective
19:53:13 <luke-jr> that is a sensible one
19:53:15 <BlueMatt> we dont need more options in the wallet...
19:53:19 <instagibbs> anyways, all i have to say. Let's fix the wallet.
19:53:35 <gmaxwell> I don't share his concern, but even if I did-- his fix isn't needed for it:  anyone autoconverting an address has a serious risk of funds loss already.
19:53:41 <provoostenator> luke-jr: what's wrong with launching with -addresstype=legacy?
19:53:42 <luke-jr> BlueMatt: 12146 is trivial
19:53:44 <morcos> luke-jr: would it help if we we very publicly communicated that our philosophy is to not accept payments except for addresses which have been given out?
19:53:45 <wumpus> certainly not options that only exist for some political goal and no one will actually use nor test
19:54:14 <morcos> we discussed doing that when we were making this change, b/c we knew we'd be making things worse on that front, but we'd already crossed the bridge with addwitnessaddress
19:54:18 <luke-jr> provoostenator: the current code will still accept Segwit payments to malleated addresses
19:54:18 <morcos> and other variants
19:54:25 <BlueMatt> anyway, one more review on #12118 and slipping in past feature freeze would make me very happy...good to keep the march of performance improvements in block validation latency moving :)
19:54:27 <gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
19:54:41 <gmaxwell> luke-jr: your change isn't needed to prevent autoconverting. Anyone who 'autoconverts' will have casual funds loss due to converted outputs being unreconized by older software, and _unrecoverable loss_ due to uncompressed pubkeys and potentially HSMs.
19:54:45 <cfields> instagibbs: at best, if you wag your finger and I'm forced to re-send a non-witness tx, that's 2x the tx's for that interaction. Not doing much to reduce block size...
19:55:08 <provoostenator> luke-jr: oh, you mean someone sees the public key after you spend it and then figures out how to send to its SegWit equivalent? I'm not sure if that actually works, see my backwards compatibility test PR.
19:55:13 <gmaxwell> luke-jr: that should be ample discouragement there.
19:55:16 <wumpus> morcos: would make sense to document that, though I wouldn't know where!
19:55:28 <jnewbery> Doesn't seem to me like this needs to be discussed for v0.16 release. Luke can maintain his patch in knots and everyone is happy. And then we can reconsider 12146 for 0.16.1
19:55:28 <instagibbs> cfields, what we need is a way of bloating the weight without taking up serialization space lol
19:55:30 <luke-jr> gmaxwell: all the more reason to allow people to avoid accepting the attempts
19:55:35 <provoostenator> But I don't see the point in ignoring such a transaction. There's certainly no way to stop it.
19:55:37 <achow101> provoostenator: given a p2pkh address, you can easily make the p2wpkh output without needing to see a transaction
19:55:38 <morcos> We can use the @bitcoin twitter handle maybe
19:55:48 <meshcollider> provoostenator: you don't need the public key, segwit addresses use PKH too
19:56:02 <wumpus> but a warning against 'malleating' addresses would make sense, I mean it's bad form and just because bitcoin core happens to accept it doesn't mean other wallets do
19:56:03 <luke-jr> provoostenator: it's an invalid payment
19:56:06 <gmaxwell> And yes, as morocos said, we knew that our handling of segwit would increase the risk that someone falsely believed they could autoconvert.  It was a tradeoff we made, otherwise segwit support would be delayed behind a massive redesign.
19:56:23 <luke-jr> morcos: It would probably be good to do so, but I'm not sure it accomplishes the same thing
19:56:40 <luke-jr> also, you *can't* malleate right now
19:56:41 <morcos> yes, so lets spend our time doing the redesign and communicating our intentions
19:56:42 <cfields> instagibbs: heh
19:56:50 <morcos> you can do other forms of malleation
19:56:52 <BlueMatt> </topic>? It seems like everyone agrees outside of luke, and there is a *real* solution...also easy to not use 0.16 for now
19:56:59 <sipa> luke-jr: you can use p2pk instead of p2pkh
19:57:04 <wumpus> BlueMatt: yes, any other topics?
19:57:07 <Chris_Stewart_5> PSA: if anyone is interested in talking more about #12131 or #12132 there is a development channel that some work has been occurring in: #bitcoin-mast
19:57:08 <gribble> https://github.com/bitcoin/bitcoin/issues/12131 | [BIP-98 + BIP-116] MERKLEBRANCHVERIFY by kallewoof · Pull Request #12131 · bitcoin/bitcoin · GitHub
19:57:10 <gribble> https://github.com/bitcoin/bitcoin/issues/12132 | [BIP-117] Tail call semantics by kallewoof · Pull Request #12132 · bitcoin/bitcoin · GitHub
19:57:12 <wumpus> oh 3 minutes to go
19:57:12 <luke-jr> sipa: only if you know the key, which only the recipient does
19:57:27 <morcos> aren't those a bit premature for PR's?
19:57:29 <arubi> sipa, then I'll trick you into accepting some big bare n-of-m with a bunch of pubkeys
19:57:29 <achow101> luke-jr: you can malleate it to a p2sh nested p2pkh
19:57:34 <gmaxwell> luke-jr: I think it's adequate enough to let people know that if they do that, they _will_ lose funds, its effectively a guarentee.  some switch to willfully ignore the outputs in a recoverable way wouldn't help that message at all.
19:57:37 <arubi> (all of yours)
19:57:41 <gmaxwell> and basically no one but you would set it.
19:57:41 <morcos> is there any consensus at all around wanting those features?
19:57:51 <luke-jr> achow101: nope, pretty sure we won't accept that without adding it to the wallet explicitly
19:58:09 <sipa> achow101: as luke-jr says
19:58:14 <luke-jr> gmaxwell: I don't agree only I would set it.
19:58:24 <gmaxwell> luke-jr: you can malleat addresses now fwiw, this is a long term design flaw in the wallet.
19:58:31 <gmaxwell> oh sipa pointed that out too
19:58:39 <luke-jr> gmaxwell: but you can't, as I pointed out
19:58:39 <wumpus> there's not really incentive for anyone to set a 'ignore some payments to me' setting, real user complaints are about not receiving payments...
19:58:41 <Chris_Stewart_5> morcos: I would say they are premature -- but I think they are definitely worht exploring more
19:58:41 <instagibbs> you can send people naked multisig...
19:58:42 <instagibbs> lol
19:58:51 <Chris_Stewart_5> if that was directed at me
19:58:55 <sipa> instagibbs: indeed
19:58:58 <luke-jr> instagibbs: !
19:59:03 <gmaxwell> luke-jr: something like 80% of addresses are reused...
19:59:05 <arubi> and with a bunch of pubkeys
19:59:19 <morcos> Chris_Stewart_5: yes...  i just wasnt sure if i was behind the times...
19:59:27 <luke-jr> gmaxwell: unsupported use case, not relevant to the discussion, but instagibbs found an example case
19:59:27 <gmaxwell> as wumpus says, the incentives are against setting that knob.
19:59:40 <instagibbs> I guess that's another argument, there are tons of ways of malleating it, let's just fix the wallet instead.
19:59:42 <Chris_Stewart_5> morcos: Also why we should discuss the development in a separate channel IMO as it is a little speculative still
19:59:44 <wumpus> gmaxwell: also thanks to some exchanges that have a limit on the number of deposit addresses
19:59:46 <sipa> instagibbs: indeed
20:00:06 <sipa> DING
20:00:10 <wumpus> #endmeeting