19:00:15 #startmeeting 19:00:15 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:21 #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 hi 19:00:40 congrats everyone on merging segwit wallet! 19:00:47 \o/ 19:00:48 hi 19:01:04 I think we should focus this meeting on what there is to do still for 0.16 19:01:21 hi 19:01:22 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 hi 19:01:31 \o/ so great to see 19:01:32 (well, moving it forward to 0.17) 19:02:18 I'd like to get either #11991 or #11937 in so non-tech-savy people can actually use bech32. 19:02:21 https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub 19:02:23 so that is the "high priority" list for now, if there's anything that should be added let me know 19:02:23 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 #11281 needs rebase and resolution of current discussion 19:02:31 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 Will do soon 19:02:46 provoostenator: agreed 19:02:59 I'll try to keep them fresh based on feedback. 19:03:05 -qt support for address types i think is a big ? still 19:03:08 Yes. I also think 11991 11937 should go into 0.16 19:03:13 I believe there's still pending segwit wallet stuff in some rpcs that are still TODO 19:03:14 sipa? 19:03:15 If 11281 goes in, I would like to also have #11200 19:03:17 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 hi, here 19:04:05 also #12101 and #12104 are bugfix-ish 19:04:06 bech32 change behavior is nice to have; #11991 is mostly for my own OCD and I can just run that myself 19:04:07 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 https://github.com/bitcoin/bitcoin/issues/12104 | HTTP Error 404: Not Found 19:04:09 https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub 19:04:32 s/12024/12104 19:04:33 do we want to fix the non-regression rpc too-many-sockets thing given its an upstream bug? cfields? 19:04:37 (sorry, I meant #12119) 19:04:39 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 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 11200 seems more like a feature and isn't necessarily segwit related 19:05:25 more for 0.17 19:06:20 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 *it won't 19:06:45 provoostenator: yes 19:07:28 wumpus: tend to agree re: 11200, though I'd still very much like to see #11281 19:07:31 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 Will we have the signing certificates ready for the release? jonasschnelli cfields 19:07:49 wumpus: consider the maxing fd's question a topic suggestion. I'm unsure what to do there. 19:07:58 BlueMatt: isn't that one already on there? 19:08:16 meshcollider: at least there is a static non distributed RSA cert now available... (OSX). 19:08:32 wumpus: it is, was just re-enforcing :) 19:08:35 jonasschnelli: ok 19:08:47 (but no clue about Windows) topic? 19:08:52 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 BlueMatt: but yes I agree keeping that, it's more of a fix I guess (but also not really) 19:09:38 o/ 19:10:08 meshcollider: I've written up a few little things worth committing, I'll PR those today as well. 19:10:09 great news regarding the signing key 19:10:15 cfields: ok, topic noted 19:11:22 oh, on to me then? 19:11:45 #11785 is what I'm unsure about 19:11:46 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 #topic maxing out fds 19:12:15 oops, accidentelly tagged #12101 0.17 while it should be 0.16 19:12:16 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 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 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 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 cfields: I think the usual way is to leave ulimit setting to the user/sysadmin 19:13:49 provoostenator, i think normally there is a feature freeze on master before creating the release branch 19:14:16 yes, normally there's a feature freeze 19:14:34 I also need to open translations for 0.16 19:14:35 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 but iirc gmaxwell was generally in favor of a general bump 19:15:02 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 wumpus: ok, mind commenting there? I'll poke gmaxwell again about it too 19:15:45 19:15:51 cfields: sure 19:15:59 thanks :) 19:16:01 other topics? 19:16:04 I have a short disussion request for 11281 19:16:07 https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e 19:16:16 Is that a concern (see commit above)= 19:16:17 ? 19:16:35 wumpus what are these "fds" to max out? 19:16:40 #topic "Avoid permanent cs_main/cs_wallet lock during RescanFromTime" discussion (jonasschnelli) 19:16:44 sipa brought up the point, but I think it's okay if we just mention that in the rpc help 19:16:45 jtimon: "file descriptors" 19:16:49 thanks 19:17:23 background: you may import a key and can see it's there but the related transactions are (still) missing 19:17:33 I think it's fine to mention that in the help 19:17:34 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 but sipa is the one who brought it up and apparently is mia today 19:18:05 Okay. Lets wait on his feedback 19:18:08 the alternative would be to block those calls during a rescan, right? 19:18:09 19:18:17 other topics? 19:18:20 what happens today if you import and then it crashes? 19:18:24 Other PRs that would be nice for 0.16 are the RPC changes in #7965 (#10583, #11415, #10579) 19:18:26 https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub 19:18:29 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 https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub 19:18:33 promag: I guess the same problem 19:18:35 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 hi. 19:18:48 jnewbery: those have nothing to do with segwit, so I moved them to 0.17 19:19:02 Agree 19:19:19 Shame. They deprecate the RPCs but don't remove them, so we're stuck with those wallet dependencies until v0.18 19:19:46 if we do a "theme release" at all we need to focus, sorry 19:19:48 jonasschnelli: should we "mark" those addresses until the rescan finishes? 19:19:51 11415 maybe could be merged now 19:19:58 do #8994 and #10757 have a chance to get merged for 0.16 if I fix the nits? 19:20:00 jonasschnelli: future work I guess 19:20:01 https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 19:20:05 https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub 19:20:13 promag: Yes... probably... need to think about that first 19:20:19 no, we're not adding non-segwit features for 0.16 19:20:29 wumpus: oooo, "theme release", can we start themeing based on cocktails like openwrt? 19:20:41 presumably 0.17 will be sooner than the usual 6 months? 19:20:48 ok so feature freeze has already started? 19:20:51 BlueMatt: lol! 19:21:02 ryanofsky, non-segwit ff i believe so 19:21:04 I think since merging SW wallet freeze is active 19:21:06 ryanofsky: for non-segwit things, yes, for segwit things it's open for sicussion 19:21:07 BlueMatt: by that you mean "white russian" (or something) for ~5 years, iirc? 19:21:07 qt stuff might still be required 19:21:08 yes, didnt we say feature freeze when segwit wallet got merged 19:21:10 ryanofsky: I'm guessing feature freeze started last night as soon as 11403 merged 19:21:22 BlueMatt: yes 19:21:22 cfields: yea...... 19:21:31 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 no 19:21:42 btw, 17 theme is? 19:21:53 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 promag: white russian, apparently 19:22:13 no theme for 0.17, no themes again please, back to simply time based releases 19:22:24 wumpus: you mean 17.0 ;) 19:22:34 Given that the world demands SegWit from the Core wallet, I tend to agree about feature freeze for non-SegWit stuff. 19:22:43 BlueMatt: it seems tohe feature freeze is being done sooner than that 19:22:49 And I guess it's about hte regular time to release anyway? 19:22:52 segwit was an exception because that was 'promised' for 0.15.1, I don't think this should become routine 19:23:27 provoostenator: I think there's still 2 months left for the usual timing 19:23:51 yes, we're intentionally trying to do the release sooner than the usual planning 19:24:12 (e.g. the one in #11449 is worst-case) 19:24:13 https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub 19:24:30 Is #10387 a blocker for 0.16? 19:24:33 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 MarcoFalke: no... can go into 0.17 IMO 19:24:53 MarcoFalke: I don't know, let's discuss 19:24:54 Or why would it be? 19:24:59 I thought the only blocker for 0.16 was #11403 ? 19:25:03 its pending on gmaxwell, just need his ack, I think 19:25:05 https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub 19:25:34 but, its def a "feature" 19:25:38 10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that 19:25:39 we're doing the bit announce on master already 19:25:46 ok moving it to 0.17 19:25:48 so thats ok for it to go 17 19:26:14 Ah,.. did 10387 still had the 0.16 tag?, Yes. Needs a 0.17 then 19:26:35 that leaves 13 open things in https://github.com/bitcoin/bitcoin/milestone/30 19:26:51 (including the release notes and the release schedule itself) 19:27:25 oops, i'm here 19:27:33 lol 19:27:35 timezone confusion 19:28:02 sipa: plx comment on 11281 19:28:02 we need a core meeting alarm/notification service 19:28:12 also pending segwit wallet work 19:28:16 whats still missing? 19:28:18 Does anything actually need to be done for #11048 19:28:19 https://github.com/bitcoin/bitcoin/issues/11048 | Weird gettransaction details on testnet with segwit · Issue #11048 · bitcoin/bitcoin · GitHub 19:28:20 sipa, Bluemat refers to https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e 19:28:40 How do I add myself to the fancy meeting username mention ping? 19:28:55 gotta tip wumpus some bch 19:29:23 lol 19:29:23 instagibbs: lol 19:29:25 yeah will do, on my phone in a bar now 19:29:36 RWC? 19:29:40 instagibbs: please no, no need to threaten me, will add him :) 19:29:51 instagibbs: yes 19:30:18 sipa: woke up in a bar? 19:30:42 BlueMatt: just charged my phone and saw your signal msg 19:30:43 heh 19:31:22 so apparrently BlueMatt is the core meeting alarm service 19:31:26 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 any other topics? 19:32:19 hi 19:32:27 instagibbs: #11991 19:32:27 [13bitcoin] 15kekimusmaximus opened pull request #12158: Avoid unnecessary copy of objects. (06master...06avoid_copies) 02https://github.com/bitcoin/bitcoin/pull/12158 19:32:30 https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub 19:32:37 lol, ok, everyone's here, start over now? 19:32:39 #12146 should be tagged 0.16 too 19:32:40 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 Bit of discussion about the UI... but otherwise ready to go. 19:33:03 ^ 11991 seems like an obvious and easy win. 19:33:16 #11991 19:33:19 https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub 19:33:44 indeed, I'd also suggest the bech32 change thing 19:34:20 yes, the "use native change if destinations are native"? I think that makes a lot of sense. 19:34:24 #12119 19:34:26 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 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 both 11991 and 12119 are already in the 0.16 milestone 19:34:53 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 What about inputs? 19:35:17 arguably you could just uniformly ranomly pick the address type of 1 of the inputs, and make the change that 19:35:26 provoostenator: I think they're irrelevant. 19:35:41 sipa: sounds like a plan 19:35:47 sipa: I don't think that makes any sense. 19:35:53 As in: if any input or any output is bech32, use bech32, unless changeaddress param says otherwise. .... ok, why intput irrelevant? 19:35:54 wumpus: 12146 isn't yet. 19:36:04 * sipa meh 12146 19:36:09 luke-jr: seems like that needs some more discussion 19:36:09 Why would it possibly be relevant in any way? 19:36:13 we want to frustrate chain analysis, mimicking the payment as much as possible is ++ 19:36:19 gmaxwell: what if someone wants 0.16 to behave like 0.15? 19:36:39 wumpus: releasing Segwit wallet without it is a problem for people who don't want to use Segwit. 19:36:43 We also want to reduce fees. 19:36:50 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 luke-jr: define don't use? 19:37:16 luke-jr: just don't use the segwit address types then? 19:37:17 But that doesn't apply if the outputs (any of them, arguably) are native. 19:37:20 jonasschnelli: never have a Segwit UTXO despite what anyone else may do 19:37:25 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 wumpus: without 12146, people can malleate your address and you'll never know 19:37:39 provoostenator: no! 19:37:42 provoostenator, ?? 19:37:52 is address malleation a thing now? 19:37:59 It saves fees and there's no privacy downside, what am I missing? 19:38:07 luke-jr: they can already 19:38:11 Again, inputs are irrelevant-- I can't figure out why you think inputs are at all relevant. 19:38:12 provoostenator: he's worried about block size increase 19:38:17 and have forever 19:38:24 as sipa said,.. it was also possible by p2pk -> p2pkh 19:38:27 sipa: with 12146, you would at least notice / not accept it 19:38:36 luke-jr: why not? it's cheaper! 19:38:38 s/was/is 19:38:48 sipa: what? 19:39:03 would anyone use that at all, why would it be worth maintaining? 19:39:12 you're lucky if someone sends you a witness output instead anyone of p2pkh 19:39:13 I think luke-jr argument are more political/philosophical then technical/economical 19:39:20 it just complicates all kinds of logic 19:39:29 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 wumpus: because using Segwit enables miners to increase block size, and has no benefits for the current wallet. 19:39:37 i think this is going to be another "no one else agrees" type argument, sorry luke-jr 19:39:39 (i think it's really bad that we accept outputs to addresses we didn'√ give out) 19:39:41 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 but it's not specific to segwit, and needs fixing independently 19:40:07 simply not handing out those addresses should be enough... sender doesn't care if you want to spend more later 19:40:10 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 instagibbs: the sender can trick you into accepting Segwit without 12146 19:40:27 instagibbs: indeed 19:40:35 luke-jr, worse, the sender *wont know* you don't implictly convert, leading to a orphaned utxo! 19:40:36 'trick you into accepting segwit' 19:40:48 whatever jerk is doing that 19:40:48 But if the other outputs are native, then this issue doesn't exist. 19:41:00 instagibbs: orphaned UTXO is exactly the expected outcome 19:41:04 instagibbs: and that's his fault 19:41:06 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 ..... 19:41:11 man, that sounds like it should be prosecuted as a war crime 19:41:32 Alright, so rule should be: ignore inputs, if any output is bech32, use bech32 for change, unless setting overrides? 19:41:36 Chris_St1: there's two parallel conversations going on here now :/ 19:41:49 luke-jr: yes, IRC needs threads 19:42:09 #topic when to use bech32 for change 19:42:11 ^^ 19:42:13 provoostenator: yes that's most sensible 19:42:16 provoostenator: thats not a bad idea, imo 19:42:17 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 Chris_St1, privacy mostly 19:42:37 provoostenator: thats my belief. 19:42:41 Was sipa suggestion of random choice serious or a joke 19:42:44 Chris_St1: _any_ output, not _all_ 19:42:49 meshcollider, serious to me, makes sense 19:43:00 IMO any output makes sense. 19:43:01 provoostenator: I think someone could reasonable argue that it should be "if a majority" rather than any. 19:43:03 don't you lose the change privacy if there's a mix of segwit output types, though? 19:43:04 Yeah was unsure if there's any downside 19:43:09 meshcollider: I think he was serious, it makes sense, less deterministic the change choice the better 19:43:33 instagibbs: yes, but what if you a 3 segwit payment outputs and 2 p2pkh payment outputs, what is the change type? 19:43:37 I think "all" is obviously too strong. 19:43:37 if there's a p2wsh output and change goes to p2wpkh, that's obvious 19:43:53 Chris_St1, arguments to be had. Could flip weighted coin, could just pick the cheapest to mimic 19:44:00 (native) 19:44:03 cfields: "segwit" here means native. 19:44:04 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 So I like provoostenator's idea 19:44:24 Chris_St1: bech32 in my proposal s well as the majority proposol (which I think it's a bit complicated...) 19:44:28 morcos: But that erodes the privacy of *everyone*. see zcash? 19:44:59 Chris_St1: i don't think that analogy applies 19:45:03 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 yea, majority-are-native or signle-is-native are both fine with me 19:45:13 weighed random? 19:45:31 I think it's okay to bias some here towards the more cost effective form. 19:45:36 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 yes 19:45:38 hiding with other segwit wallets imo is your best bet anyways... 19:45:49 also the difference between these things only matters for sendmany... 19:45:52 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 any-output-is-native seems reasonable to me 19:46:41 same 19:46:42 sipa: I think my suggestion was "unless configured that change should be legacy, change is native if any output is native". 19:46:57 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 As for luke-jr's point: having some flag to completely opt-out of SegWit seems reasonable to me. 19:47:04 (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 gmaxwell: and p2sh-p2wsh otherwise? 19:47:13 sipa: yes. 19:47:20 makes snese 19:47:35 gmaxwell: by native you mean p2wpkh? 19:47:41 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 morcos, if it has native change is native is entirely determinstic, luckily 19:48:21 sorry, has native, comma, change is native 19:48:52 morcos: I think you were responding to things like "weighed random change types" 19:49:03 correct 19:49:06 more topics? 19:49:24 back to 12146? 19:49:26 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 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 luke-jr, Creating utxo bloat to *slightly* reduce blocksize is weird weird feature to add imo 19:49:51 (if we've transitioned) 19:49:57 instagibbs: it's not UTXO bloat. 19:50:10 luke-jr: nack, just use 0.15.1 and focus on the real fix of splitting hd chain 19:50:11 the scenario here is that some joker pays you, and you don't want to spend it, right? 19:50:25 +1 BlueMatt 19:50:30 alternatively, this could be accomplished by using labels/accounts 19:50:40 label addresses and then payments will show up without the labels 19:50:44 instagibbs: more or less 19:50:57 BlueMatt: NACK, to myself and many others, mandatory Segwit wallet is a regression 19:51:06 then dont use 0.16 19:51:15 so 0.15 is supported forever? 19:51:19 luke's argument is lame but there are other arguments for the position... But I think it's ultimately futile. 19:51:21 including new features? 19:51:31 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 if you want the option, do the real fix, not the dirty hack of working like 0.15.1 19:51:33 luke-jr: by anyone who cares to support it 19:51:36 This feature doesn't make any sense to me though. 19:51:55 BlueMatt: there isn't a better fix 19:51:56 (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 ^ it's in sipas gist 19:52:11 luke-jr: the real fix is using different hd paths 19:52:13 indeed. 19:52:14 which sipa proposed (I believe to much agreement) as the long-term route for the wallet 19:52:15 BlueMatt: that's more than a fix. :p 19:52:17 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 gmaxwell, no I get the issue 19:52:30 I don't get his fix, it's one-sided 19:52:39 ah. 19:52:56 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 sender has no clue you won't accept it!(outside of us wagging fingers to not try it) 19:53:02 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 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 that is a sensible one 19:53:15 we dont need more options in the wallet... 19:53:19 anyways, all i have to say. Let's fix the wallet. 19:53:35 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 luke-jr: what's wrong with launching with -addresstype=legacy? 19:53:42 BlueMatt: 12146 is trivial 19:53:44 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 certainly not options that only exist for some political goal and no one will actually use nor test 19:54:14 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 provoostenator: the current code will still accept Segwit payments to malleated addresses 19:54:18 and other variants 19:54:25 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 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 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 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 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 luke-jr: that should be ample discouragement there. 19:55:16 morcos: would make sense to document that, though I wouldn't know where! 19:55:28 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 cfields, what we need is a way of bloating the weight without taking up serialization space lol 19:55:30 gmaxwell: all the more reason to allow people to avoid accepting the attempts 19:55:35 But I don't see the point in ignoring such a transaction. There's certainly no way to stop it. 19:55:37 provoostenator: given a p2pkh address, you can easily make the p2wpkh output without needing to see a transaction 19:55:38 We can use the @bitcoin twitter handle maybe 19:55:48 provoostenator: you don't need the public key, segwit addresses use PKH too 19:56:02 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 provoostenator: it's an invalid payment 19:56:06 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 morcos: It would probably be good to do so, but I'm not sure it accomplishes the same thing 19:56:40 also, you *can't* malleate right now 19:56:41 yes, so lets spend our time doing the redesign and communicating our intentions 19:56:42 instagibbs: heh 19:56:50 you can do other forms of malleation 19:56:52 ? 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 luke-jr: you can use p2pk instead of p2pkh 19:57:04 BlueMatt: yes, any other topics? 19:57:07 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 https://github.com/bitcoin/bitcoin/issues/12131 | [BIP-98 + BIP-116] MERKLEBRANCHVERIFY by kallewoof · Pull Request #12131 · bitcoin/bitcoin · GitHub 19:57:10 https://github.com/bitcoin/bitcoin/issues/12132 | [BIP-117] Tail call semantics by kallewoof · Pull Request #12132 · bitcoin/bitcoin · GitHub 19:57:12 oh 3 minutes to go 19:57:12 sipa: only if you know the key, which only the recipient does 19:57:27 aren't those a bit premature for PR's? 19:57:29 sipa, then I'll trick you into accepting some big bare n-of-m with a bunch of pubkeys 19:57:29 luke-jr: you can malleate it to a p2sh nested p2pkh 19:57:34 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 (all of yours) 19:57:41 and basically no one but you would set it. 19:57:41 is there any consensus at all around wanting those features? 19:57:51 achow101: nope, pretty sure we won't accept that without adding it to the wallet explicitly 19:58:09 achow101: as luke-jr says 19:58:14