19:05:13 <sipa> #startmeeting
19:05:13 <lightningbot> Meeting started Thu Aug  9 19:05:13 2018 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:05:22 <sipa> topics?
19:06:16 <sipa> we still have quite a few PRs marked 0.17
19:06:36 <sipa> should we discuss low-R sigs?
19:07:03 <achow101> +1
19:07:08 <jonasschnelli> hi
19:07:11 <meshcollider> #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 provoostenator
19:07:17 <meshcollider> hi
19:07:20 <jnewbery> 01:59 < aj> wumpus: in case i'm not awake for the meeting, topic suggestion: lower tx fees, pr #13922 :)
19:07:21 <meshcollider> +1
19:07:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
19:08:17 <sipa> perhaps first let's ask around if there are things for 0.17 that deserve the milestone
19:09:17 <sipa> i guess that's a no
19:09:22 <sipa> #topic low-r signatures
19:09:35 <Murch> hi
19:09:40 <sipa> pull request #13666
19:09:43 <gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHubAsset 1Asset 1
19:09:47 <wumpus> ohh sorry!
19:10:06 <luke-jr> wumpus: too late, you're fired :p
19:10:17 <wumpus> luke-jr: :p
19:10:38 <sipa> one issue with the approach is that we need to guess whether signatures created by other software will be assumed to be 71 bytes as well
19:10:49 <sipa> as brought up by wumpus in the PR
19:11:05 <sipa> (for size estimation purposes)
19:11:17 <wumpus> yes the size estimation is the only controversial part there imo
19:11:29 <achow101> this is only a problem when we select watching-only inputs
19:11:29 <sipa> as we're getting closer to branching off, i wonder if we shouldn't just punt on that
19:11:32 <wumpus> obviously it's better to generate smaller signatures where possible
19:11:52 <gmaxwell> well we could easily make the size estimate 71 for our keys, and 72 otherwise, and worry about the difference later.
19:11:58 <sipa> achow101's code right now will assume 71 byte signatures if we have the keys for everything, and 72 in any other case
19:12:12 <Murch> That seems safe.
19:12:12 <wumpus> that heuristic makes sense I think
19:12:17 <gmaxwell> that seems reasonable enough.
19:12:34 <gmaxwell> even if we always estimated 72, I'd rather make the smaller signatures.
19:12:43 <wumpus> exactly, it's kind-of independent
19:12:51 <sipa> yes, i don't think the discussion is about whether or not to produce 71 byte signatures
19:12:56 <sipa> we should always do so
19:13:05 <achow101> imo estimating 72 bytes kind of defeats the purpose of producing 71 byte sigs
19:13:15 <Murch> it doesn't
19:13:17 <wumpus> it still takes less space in the block chain.
19:13:18 <gmaxwell> achow101: might defeat _your_ purpose. :P
19:13:22 <luke-jr> achow101: nah, you get value in feerate
19:13:28 <Murch> You're still getting a higher effective fee rate and block space savings
19:13:30 <wumpus> and you get better feerate, yep
19:13:39 <gmaxwell> what wumpus said. it still economizes use of a public resource, and you still get higher priority.
19:14:06 <sipa> in any case,
19:14:10 <sipa> #action review 13666
19:14:22 <sipa> it adds a bit of complexity by adding a second dummy signer
19:14:27 <Murch> might save some 3kB per block or so.
19:14:39 <Murch> If everyone did it
19:15:16 <wumpus> yes
19:15:33 * luke-jr wonders if we should look into getting rid of the Segwit dummy/flags too
19:15:35 <provoostenator> You can always add a param to the RPC that says "assume 71 "
19:15:48 <luke-jr> ofc that doesn't affect the consensus limits, so not incentivised :/
19:16:08 <sipa> well, thinking ahead, we may need that anyway - in case more complicated scripts are supported, the size may depend on what subset of signers is present
19:16:16 <sipa> but that seems too late for 0.17
19:16:24 <wumpus> provoostenator: I'm... not sure it's good to add such little implementation details to RPC, but maybe a more general fee estimation strategy can be exposed such way
19:16:34 <wumpus> yes, definitely
19:16:43 <provoostenator> Luckily the RPC is experimental
19:16:47 <gmaxwell> rpc would be a bad place for it
19:16:52 <sipa> or rather, we may need to add a way to pass in information about other signers to transaction creation RPS
19:16:55 <sipa> RPCs
19:16:59 <Murch> @provoostenator: I don't think that there is sufficient use of multi party transactions and savings to add a param for that.
19:17:01 <gmaxwell> the right place would be as metadata on the keys/outputs in the wallet.
19:17:12 <sipa> gmaxwell: how so?
19:17:22 <sipa> ah yes, but the 71/72 thing - agree
19:18:23 <sipa> luke-jr: i don't know what you're referring to?
19:18:24 <gmaxwell> sipa: just that the size of an scriptpubkey's signature is just a property of the private key(s).
19:18:34 <sipa> gmaxwell: yes, indeed
19:18:40 <gmaxwell> just like the pubkey part of the scriptsig being 65 or 33 bytes.
19:19:57 <sipa> do we have other topics?
19:20:01 <gmaxwell> in any case, for now its fine to just assume 72 unless we know otherwise. In the future we can be smarter.
19:20:14 <Murch> the problem will be permanently solved by the new signature encoding that is proposed for Schnorr signatures anyway.
19:20:18 <luke-jr> sipa: just that the dummy 2 bytes in every Segwit tx could be eliminated on the network/disk level, if we're trying to focus on micro-optimisations of space
19:20:39 <gmaxwell> luke-jr: far far better than that can be done.
19:20:51 <sipa> luke-jr: sure; and much more than that, we should look into compressing all data on the wire
19:20:58 <sipa> we have someone looking into that
19:21:05 <meshcollider> You had a whole write-up on a compressed transaction format earlier didn't you
19:21:23 <sipa> meshcollider: yes, there's a bunch of improvements and simplifications
19:21:27 <sipa> which we haven't published
19:21:46 <sipa> 19:07:19 < jnewbery> 01:59 < aj> wumpus: in case i'm not awake for the meeting, topic suggestion: lower tx fees, pr #13922 :)
19:21:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
19:21:55 <sipa> #topic lower tx fees, pr 13922
19:22:30 <Murch> "it changes the min tx fee to 200 s/B, and the incremental relay fee to 100 s/B" doesn't he mean s/kB?
19:22:53 <gmaxwell> and is that kVB  not B?
19:23:07 <jnewbery> (I don't have any input on this topic except to concept ACK the PR. Only relaying aj's earlier message)
19:23:07 <Murch> yeah, kvB
19:23:44 <gmaxwell> I feel pretty meh about dropping feerates. I guess 200 isn't that much of a change but at some level we get back in spamflood level land.
19:23:57 <sipa> i have no opinion on this topic
19:24:18 <luke-jr> it's low enough I don't care; I'd prefer to see users adopt changes manually rather than top-down default modifications, but meh
19:24:31 <Murch> gmaxwell: I think that reducing the fee could drive some UTXO consolidation
19:24:52 <gmaxwell> or cause waiting until it's dropped further.
19:25:04 <luke-jr> Murch: if that's the goal, maybe it should explicitly look for that
19:25:43 <Murch> I've observed that time preference signaling has improved a lot this year. One of our customers explicitly waited for us to allow a fee rate of 2 sats/B before consolidating.
19:26:05 <Murch> If 0.2 sats/B were possible, I'd not be surprised to see some more of that.
19:27:23 <gmaxwell> Well lets try it, but if things go wonky it can be set back.
19:27:34 <Murch> We do have small fee spikes every now and then again. I think that we'd get a backlog of consolidations at least part of the time, hopefully consistently in the future.
19:27:56 <Murch> The biggest issue is that most miners don't mine anything below 1 sats/B
19:28:14 <gmaxwell> in terms of the patch, I'm not sure it's doing it correctly as is.  Basically we must lower relay and mining behavior before wallet... changing the estimator to allow low estimates before we know they reliably propagate will cause stuck users.
19:28:21 <Murch> (showing as a solid backlog below 1 sat/B, even when blocks have space left)
19:28:34 <luke-jr> Murch: well, if that's the case, it would be bad to drop relay fees lower
19:28:59 <Murch> I don't follow.
19:29:08 <gmaxwell> luke-jr: the theory is if the defaults change the behavior will too.
19:29:08 <sipa> luke-jr: i'm sure miners don't allow below 1 vsat/B _because_ the network doesn't relay them
19:29:36 <Murch> Ah I see.
19:29:40 <gmaxwell> Murch: luke's point is that we shouldn't be relaying things that won't get mined.
19:29:51 <Murch> Yeah, miners tend to lag behind on adoption of new versions
19:30:10 <luke-jr> has anyone discussed this with any miners?
19:30:18 <Murch> It would already help if we found a few percent of the hash rate that tells us they would support it
19:30:34 <luke-jr> Murch: this is a matter of policy, not versions. defaults are just defaults.
19:30:41 <sipa> so 1) reduce the minimum feerate the mining code works at 2) if/when that gets adopted, start relaying below 1 3) if/when that gets adopted, make fee estimation work with it
19:30:59 <Murch> My suspicion is that most miners don't much fiddle with defaults.
19:31:31 <Murch> seems like a reasonable order of things
19:32:00 <luke-jr> Murch: they should. this is their job, not developers'
19:32:30 <gmaxwell> can we not have this debate here and now.
19:32:34 <provoostenator> My main concern with allowing sub 1 satoshi / vbyte fees is that - when fees are low - there's going to be a good chance the users transaction doesn't propagate.
19:32:37 <gmaxwell> it's really tedious.
19:32:46 <Murch> luke-jr: IF they were engaging at that level of the technology, they wouldn't be running mining operations of RaspberryPis, lag behind multiple versions causing orphans, and similar things.
19:33:13 <gmaxwell> provoostenator: that was my comment above, relay/mining behavior needs to change ahead of wallet behavior, they can't both change at once.
19:34:09 <provoostenator> gmaxwell: ah I see, by keeping the wallet minimum at 1 sat / byte, that makes sense.
19:34:11 <phantomcircuit> gmaxwell, mining needs to change, then relay, then wallet
19:34:19 <phantomcircuit> but none of the first two have a reason to change without the later
19:34:20 <phantomcircuit> sooo
19:34:21 <achow101> gmaxwell: so at best, this would need to be deployed across two versions
19:34:39 <gmaxwell> achow101: yes.
19:34:41 <wumpus> at least
19:34:47 <achow101> which means, at this point, it's a year and a half out
19:34:59 <achow101> and by then, who knows what fees will be like
19:34:59 <luke-jr> they can be minor versions
19:35:00 <phantomcircuit> achow101, and realistically miners do change the defaults so...
19:35:01 <wumpus> it depends, we can see the adoption
19:35:30 <wumpus> and decide when (if ever) the wallet part can go in
19:35:32 <gmaxwell> as luke-jr says. also users can locally override their wallets once they know that lower rates will confirm.
19:35:37 <wumpus> yes
19:35:59 <gmaxwell> phantomcircuit: we can handle some things getting relayed that don't get mined at least... (now, not so much years ago)
19:36:07 <Murch> phantomcircuit: It's enough if a portion of the hashrate adopts the change to make it's use a viable strategy for low time-preference txes.
19:37:04 <Murch> Talking to miners would be a good idea
19:37:39 <gmaxwell> I'd really like it if there wouldn't need to be these thresholds at all, but unfortunately, solving making it all automatic seems excessively hard.
19:38:14 <gmaxwell> In any case, I'd review and ack a split up that moved the relay/mining defaults and left the wallet parts up for a later version.
19:40:45 <sipa> any other topics?
19:40:46 <Murch> So, pseudowumpus sipa, anything else on your agenda?
19:41:04 <luke-jr> gmaxwell: I thought the current PR already left wallet alone
19:41:09 <phantomcircuit> gmaxwell, automating all these levels would be vastly simplified by efficient mempool sync
19:41:13 <gmaxwell> luke-jr: ah, haven't checked.
19:41:14 <phantomcircuit> which im sure you know :P
19:41:36 <sipa> phantomcircuit: you can't automate the decision on incremental relay feerate
19:41:45 <sipa> as it's not mempool dependent but bandwidth cost dependent
19:42:47 <sipa> wumpus: you have any other topics?
19:43:00 <luke-jr> sipa: not your own nodes cost directly, though? since you're not getting paid for it; so measuring bandwidth availability may be sufficient?
19:43:42 <wumpus> nope!
19:43:43 <sipa> luke-jr: if you'd set it to 0, you can be pushed into arbitrarily high bandwidth usage by an attacker
19:43:50 <wumpus> the 0.17 list basically
19:44:17 <gmaxwell> luke-jr: for incremental, it's relatively important that the behavior be consistent. Thats largely at odds with automating it, unfortunately.
19:44:36 <sipa> yeah, let's just take further discussion to the individual PRs
19:44:38 <sipa> #endmeeting