19:00:25 <wumpus> #startmeeting
19:00:25 <lightningbot> Meeting started Thu Nov 29 19:00:25 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:25 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:38 <sipa> oh, meeting!
19:00:42 <dongcarl> hi
19:00:59 <moneyball> hi
19:01:04 <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 provoostenator
19:01:14 <moneyball> suggested topic: proposed meeting topics ahead of time
19:01:23 <meshcollider> hi
19:01:25 <BlueMatt> topics: 0.17.1
19:01:52 <wumpus> #topic high priority for review
19:02:30 <wumpus> current PRs: #14670 #13932 #14336 #14646
19:02:32 <gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
19:02:36 <gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
19:02:38 <gribble> https://github.com/bitcoin/bitcoin/issues/14646 | Add expansion cache functions to descriptors (unused for now) by sipa · Pull Request #14646 · bitcoin/bitcoin · GitHub
19:02:42 <gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
19:02:53 <kanzure> hi.
19:03:48 <wumpus> anyone want to add or remove anything?
19:04:07 <sipa> lgtm
19:04:25 <meshcollider> Pieter already has one but it'd be great to have #14565
19:04:28 <gmaxwell> whats the overlap with 0.17.1 tag?
19:04:29 <gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
19:04:43 <chenpo> hi
19:05:05 <wumpus> does the 0.17.1 tag have any non-backports left?
19:05:08 <gmaxwell> #14380
19:05:12 <gribble> https://github.com/bitcoin/bitcoin/issues/14380 | fix assert crash when specified change output spend size is unknown by instagibbs · Pull Request #14380 · bitcoin/bitcoin · GitHub
19:05:25 <gmaxwell> is what I was thinking of.
19:05:30 <wumpus> https://github.com/bitcoin/bitcoin/milestone/39
19:06:09 <wumpus> let's add that one then
19:06:32 <meshcollider> 14782 is sort-of not a backport
19:06:41 <jnewbery> hi
19:06:49 <wumpus> meshcollider: which one is the most-blocking?
19:07:14 <wumpus> #14646 seems like it needs to go in before something else so looks like a typical candidate at least
19:07:16 <gribble> https://github.com/bitcoin/bitcoin/issues/14646 | Add expansion cache functions to descriptors (unused for now) by sipa · Pull Request #14646 · bitcoin/bitcoin · GitHub
19:07:38 <meshcollider> Yeah don't remove that one
19:08:19 <gmaxwell> The broken getbalance behavior should get fixed. It's an actual bug.
19:08:40 <wumpus> that's only broken on 0.17 and not master?
19:08:56 <provoostenator> #14602
19:08:58 <gribble> https://github.com/bitcoin/bitcoin/issues/14602 | Bugfix: Correctly calculate balances when min_conf is used, and for getbalance("*") by luke-jr · Pull Request #14602 · bitcoin/bitcoin · GitHub
19:09:15 <achow101> hi
19:09:17 <wumpus> wait, I added #14782 which is the 0.17 backport
19:09:19 <gribble> https://github.com/bitcoin/bitcoin/issues/14782 | [0.17] Bugfix: Correctly calculate balances when min_conf is used, and for getbalance("*") by luke-jr · Pull Request #14782 · bitcoin/bitcoin · GitHub
19:09:21 <jnewbery> I'm not clear what the behaviour is 'supposed' to be. There's no documentation or test coverage
19:09:26 <gmaxwell> wumpus: not yet, there is another PR
19:09:41 <wumpus> why is a backport open before something is merged into master? is it signifiantly different?
19:09:42 <provoostenator> Ah yes, it's already marked for backport.
19:09:49 <meshcollider> The 0.17 backport of it is different yes
19:09:53 <meshcollider> Because of the accounts removal
19:09:57 <sipa> maybe the getbalance behaviour needs to be topic on its own>?
19:09:57 <wumpus> right
19:10:00 <gmaxwell> jnewbery: thats a fine concern, but it's not cool to break functionality just because there wasn't enough tests to stop you from doing so
19:10:10 <meshcollider> ping luke-jr
19:10:18 <wumpus> if there's any doubt it probably needs to stay as it was
19:10:33 <gmaxwell> The alternative of going and reverting the breaking change is unfortunately too disruptive (I already tried).
19:10:47 <meshcollider> Re-implementing the old behaviour without reintroducing account parameters is the issue
19:10:54 <jnewbery> the new behaviour in the fix is different from pre-0.17
19:11:15 <meshcollider> And it has some weird parameter type polymorphism
19:11:18 <wumpus> well for 0.18, changing the behavior can be discussed if there's agood reason
19:11:23 <sipa> gmaxwell: well given the removal of accounts, i think it's fair to say that anyone passing not-nothing as the account parameter to getbalance needs to change, and you can get the 0-conf behavior using getunconfirmedbalance
19:11:25 <jnewbery> so before we decide whether it should be merged, we should figure out what the behavious should be, document it and cover it with tests so it's not regressed
19:11:47 <provoostenator> getunconfirmedbalance _only_ includes unconfirmed balance afaik
19:11:51 <sipa> oh
19:12:00 <wumpus> for 0.17 it'd be good to go back to the old behavior because it was not announced in the release notes that it would change
19:12:01 <sipa> ignore my suggestion, again
19:12:02 <meshcollider> Add them together then :)
19:12:18 <gmaxwell> if you add them you'll double count
19:12:32 <meshcollider> wumpus: that's why the 0.17 backport was opened already
19:12:35 <provoostenator> It's useful in practice to be able to get the balance including unconfirmed, so you can compose a PSBT while you're waiting for confirmation.
19:12:36 <BlueMatt> also for 0.17.1 this seems a bit too late to be figuring out
19:12:43 <BlueMatt> we can revisit for 0.17.2 if there is one
19:12:43 <provoostenator> (without doing math)
19:13:11 <BlueMatt> but 0.17.0 currently cannot be self-built and bitcoin-qt opened on latest fedora/ubuntu release
19:13:16 <BlueMatt> both of which have been out for a bit now
19:13:17 <gmaxwell> It isn't just a question of unconfirmed or not, it's a question of your balance suddenly showing zero when you make a small payment.. because now your change is unconfirmed.
19:13:29 <sipa> gmaxwell: getbalance includes change
19:13:40 <sipa> just not unconfirmed incoming payments
19:14:02 <sipa> that was the distinction between getbalance and getbalance *, afaik
19:14:13 <wumpus> #topic getbalance
19:14:16 <gmaxwell> Right
19:14:31 <gmaxwell> sipa: and thats also why you can't add getunconfirmedbalance.
19:14:39 <jnewbery> for those without context, this is (mostly) my fault for removing accounts. The first parameter to getbalance was 'account', it was marked DEPRECATED with a warning saying 'don't use this'. I removed it and it turns out people were using it to sum up untrusted coins
19:14:53 <sipa> you can simulate "getbalance *" using "getbalance minconf=1" + "getunconfirmedbalance" i guess
19:14:56 <wumpus> BlueMatt: yes, let's discuss what to in include in 0.17.1 in the 0.17.1 topic
19:15:00 <meshcollider> But the actual difference wasn't just unspent, it was untrusted, right?
19:15:05 <sipa> meshcollider: indeed
19:15:08 <meshcollider> Unconfirmed*
19:15:27 <jnewbery> getbalance -minconf=0 includes unconfirmed but not untrusted coins (eg your change)
19:15:40 <jnewbery> getbalance * 0 would (prior to 0.17) include untrusted
19:16:00 <jnewbery> so for example if someone sent you an output, then RBF'ed it, you'd still see that in your getbalance * 0
19:16:04 <meshcollider> as you pointed out on the PR though john, does that also include conflicting transactions and stuff too?
19:16:22 <jnewbery> or RBF'ed it to you, you'd double count it
19:16:29 <jnewbery> or you could have a negative balance
19:16:57 <meshcollider> Thats not sane behaviour to keep then :/
19:17:06 <wumpus> that sounds pretty broken
19:17:08 <gmaxwell> I didn't think it included conflicteds, but actually it makes sense.
19:17:11 <jnewbery> I don't know why people were using getbalance * 0, or what they were using it for. I've asked a few times on the PR but no-one can answer
19:17:41 <gmaxwell> If you recall when we removed accounts I raised a concern that didn't we still need move to fixed people's negative balances... because we still had those reported from time to time.
19:17:58 <jnewbery> ok, I've fixed that :)
19:18:08 <gmaxwell> jnewbery: to see unconfirmed payments... it's certantly what I always did before I gave up on balances and just switched to looking at the unspent outputs directly
19:18:09 <ryanofsky> It sounded to me like people were just using it to get unconfirmed balance without having two make two calls
19:18:29 <provoostenator> That's exactly how I use it.
19:18:42 <sipa> how about adding a "requiretrusted" parameter to getbalance...?
19:18:43 <gmaxwell> ryanofsky: not just without having to make two calls, because getbalance included 0 conf trusted coins.
19:18:52 <provoostenator> If you want to prepare a transaction to spend all, you need to enter the amount to send.
19:18:53 <gmaxwell> ryanofsky: and the minconf parameter was added later
19:19:01 <jnewbery> I think it's fine to have a balance including unconfirmeds if they're trusted (ie all inputs were yours). Having a balance containing unconfirmeds that aren't trusted and so can be double-accounted or worse doesn't make sense to me
19:19:12 <meshcollider> sipa: the PR introduces a bool for trustedness
19:19:18 <sipa> meshcollider: oh!
19:19:36 <jnewbery> I strongly discourage any 'balance' that contains untrusted coins
19:19:38 <sipa> does it allow counting untrusted, while excluding conflicting etc?
19:19:44 <meshcollider> No
19:19:53 <gmaxwell> jnewbery: I don't understand "trusted and so can be double-accounted" -- even a trusted payment could be conflicted
19:20:00 <provoostenator> jnewbery: why? Isn't that implied when the user enters 0 instead of 1 confirmations?
19:20:28 <meshcollider> unconfirmed != untrusted though
19:20:41 <gmaxwell> jnewbery: we _show_ unconfirmed payments in the wallet, so it's somewhat odd and confusing that we don't have "pending balance"
19:21:10 <wumpus> the GUI does have a 'unconfirmed balance' IIRC?
19:21:27 <sipa> showing untrusted balance sounds perfectly reasonable, but it shouldn't include conflicting/... things
19:21:43 <meshcollider> We could break the getbalance output and return an array of "confirmed":, "unconfirmed":, "conflicting:
19:21:54 <jnewbery> for me 'pending balance' doesn't make sense if it can double-count conflicting transactions. It's worse that not having a pending balance at all
19:22:02 <meshcollider> ^
19:22:06 <sipa> jnewbery: i agree
19:22:07 <morcos> yes, its not clear to me what the problem is with using getbalance and getunconfirmedbalance when using -cli and the GUI already does the right thing?
19:22:07 <gmaxwell> In any case, you wanted the use case, the reason people use getbalance "*" is to (Attempt) to learn their pending balance.  What they'll have assuming nothing goes wrong.  Now if that was also double counting conflicteds and ending up negative, I think thats a bug. (and probably the origin of the negative balances I was concerned about before)
19:22:14 <wumpus> users don't know what 'untrusted balance' is supposed to be, I think exposing these kind of implementation details on the interface is a bit confusing
19:22:15 <provoostenator> I agree double counting is undesirable.
19:22:20 <jnewbery> it will make users think their money has disappeared because once one of those conflicting transactions is confirmed their balance goes down
19:22:39 <morcos> can someone clearly point out exactly what we can not do now (other than we didn't properly explain what was changing)
19:22:43 <meshcollider> luke-jr: should be here to argue the other side
19:22:45 <sipa> jnewbery: i think no getbalance* call should evr include conflicted things
19:22:49 <provoostenator> It should probably use mempool rules to figure out which transaction to ignore.
19:23:05 <sipa> provoostenator: some things do
19:23:06 <meshcollider> IMO setting min_conf to 0 is enough?
19:23:08 <gmaxwell> sipa: wait. I would think that it would include one side of a conflict...
19:23:32 <sipa> gmaxwell: oh sure; terminology
19:23:33 <wumpus> isn't it supposed to make one side of a conflict non-conflicting?
19:23:46 <sipa> i guess by non-conflicting i mean "in the mempool" ?
19:23:57 <wumpus> right
19:24:01 <gmaxwell> Good! jnewbery's comment about balances going down confused me
19:24:18 <sipa> gmaxwell: or do you think unconfirmed untrusted not-in-the-mempool unconflicted things should be counted?
19:24:22 <jnewbery> sorry, I've got to step away now. My main point is that the expected behaviour should be well documented and covered by tests
19:24:33 <gmaxwell> sipa: no. I don't.
19:24:37 <sipa> ok, good
19:24:52 <jnewbery> I've written a test script for wallet balances, but we need to agree what the behaviour *should* be before merging any of this stuff
19:25:04 <meshcollider> Agreed
19:25:08 <provoostenator> If something gets confirmed against what you would expect fromt he mempool then a balance change is fine imo, but not otherwise.
19:25:23 <sipa> so how about getbalance requires the minconf as directed, and (if trusted is directed, trusted, otherwise in-the-mempool)
19:26:03 <provoostenator> sipa: the only criteria for "trusted" is whether it's change, right?
19:26:09 <gmaxwell> I think if sipa is right that the behavior can be emulated by getbalance minconf=1 + getunconfirmed then at least we have a workaround.  Though it's always confusing to have a deault behavior which cannot be explained by some setting of the arguments
19:26:14 <sipa> provoostenator: or confirmed
19:27:27 <gmaxwell> "What is the default minconf setting of getbalance? Mu.  getbalance output shows minconf=0 for trusted outputs, and minconf=1 for others.  so trusted defaults to true? No, there is no trusted argument."
19:28:18 <sipa> gmaxwell: #14602 includes a trusted_only argument that is true by default
19:28:22 <gribble> https://github.com/bitcoin/bitcoin/issues/14602 | Bugfix: Correctly calculate balances when min_conf is used, and for getbalance("*") by luke-jr · Pull Request #14602 · bitcoin/bitcoin · GitHub
19:28:23 <provoostenator> I know the wallet makes a distinction between change and non-change when it comes to spending, which is fine, but I don't think we should do that for balance. So by default minconf=0 should show change and non-change, but not replaced-by.
19:28:39 <ryanofsky> just want to note, it looks like we didn't delete the GetLegacyBalance function, so it would be trivial to restore the old getbalance "*" behavior, if we can't figure out something better right now
19:28:44 <gmaxwell> I know 14602 does. I'm trying to imagine a world where we keep things as they are and try to release note ourselves out of it
19:29:28 <provoostenator> (as for 0.17 I'm fine with release-noting our way of it)
19:29:42 <sipa> oh, i was just trying to establish what the desired behavior is before we go discuss what to do about it
19:30:11 <provoostenator> sipa: that's a good idea
19:30:37 <sipa> and i think there is at least a rough conclusion? allow counting untrusted, but never count not-in-mempool?
19:31:12 <gmaxwell> Right, I think the desired behavior is that balances shows confirmed + trusted-in-mempool-0conf.  And that you be able to adjust the threshold for confirmed and turn the trusted-in-mempool-zeroconf on and off. And if you make the confirmed=0, it should still only count in-mempool
19:31:39 <provoostenator> (and maybe add a 4th argument along the lines of unconfirmed_change_only
19:31:53 <gmaxwell> (and potentially the arguments should just be  minconf_for_not_you=1 minconf_for_from_you=0 )
19:32:15 <sipa> i think the default of minconf=0 but trusted_only=true makes sense; if you choose trusted_only=false it should still only include confirmed or mempool things
19:32:21 <morcos> sipa: the problem with never counting not-in-mempool is if you spend a 10 BTC input to pay 0.001 BTC, and that tx doesn't go in your mempool then your balance goes down by 10 mysteriously, but thats hard to solve
19:32:36 <sipa> morcos: yeah...
19:32:53 <gmaxwell> morcos: yes, I think thats hard to solve, also it's kinda good that it goes down in that you're actually screwed for the moment :P
19:33:07 <gmaxwell> like if that txn doesn't confirm, your funds are actually stuck.
19:33:38 <gmaxwell> (until you abandon the transaction)
19:33:41 <wumpus> right
19:34:07 <gmaxwell> I guess I can argue the consequences either way, I can imagine someone losing a wallet file with lots of bitcoin in it because it showed a low balance due to some easily abandoned transactions.
19:34:08 <sipa> so i think we can work out how to implement this for 0.17 and 0.18 on the PRs or issues; no need for further design here?
19:34:52 <gmaxwell> I thought luke's PR basically implemented what we came up with here. But I'm not sure.
19:35:07 <sipa> gmaxwell: i'm not sure about the mempool part
19:35:21 <wumpus> gmaxwell: people are likely to use 'getbalance' without parameters in that case, to check wallet balance, not the specific combo that this is about
19:35:28 <gmaxwell> certantly if we're showing all unconfirmeds, including both sides of a conflict, thats bad. :P
19:36:24 <provoostenator> Luke's PR adds a trusted_only as a first parameter. I find that a fairly confusing term, so hopefully we can avoid it with the ^
19:36:37 <sipa> with the what?
19:37:02 <wumpus> trusted_only sounds really confusing to users, if you make a parameter like that you need to carefully explain in the RPC help what 'truste'd means in this setting
19:37:13 <sipa> agree, it needs documentation for sure
19:37:23 <wumpus> it's far from obvious, I don't know if we picked a good term for it
19:37:36 <provoostenator> With what you said: "allow counting untrusted, but never count not-in-mempool"
19:38:07 <provoostenator> It's already a default, so maybe just a matter of renaming and documenting it.
19:38:47 <sipa> provoostenator: it can certainly be explained more friendly as "Whether unconfirmed payments from others are excluded"
19:38:58 <provoostenator> 1. zero_conf_change_only (default: false)
19:39:07 <wumpus> sipa: that sounds much better
19:39:15 <sipa> i think we're getting in the weeds here
19:39:34 <wumpus> yes, time for next otpic?
19:39:41 <sipa> agree
19:39:43 <wumpus> #topic 0.17.1
19:39:43 <provoostenator> Next topic sounds good.
19:39:50 <BlueMatt> release time!
19:39:52 <wumpus> 20 minutes left
19:40:01 <BlueMatt> cool, release in 20 minutes? :p
19:40:02 <provoostenator> BlueMatt is the main reason Ubutnu?
19:40:07 <meshcollider> Lol
19:40:16 <BlueMatt> provoostenator: also fedora, debian testing, .......
19:40:22 <provoostenator> Because an alternative could be 0.17.0.2 like we did with MacOS. Though I'm fine with proper 0.17.1 too
19:40:25 <wumpus> still lots of backports open https://github.com/bitcoin/bitcoin/milestone/39 I guess they need review, or at least merging
19:40:33 <BlueMatt> provoostenator: also there are a number of other bugs and backports that are done, etc
19:40:36 <sipa> we have a bunch of bugfixes lined up too
19:40:37 <wumpus> nah let's do a proper release
19:40:40 <sipa> it may be time for a 0.17.1
19:40:41 <BlueMatt> things already merged on master probably worth backporting
19:40:43 <wumpus> it's too late for 0.17.0.2 IMO
19:40:46 <BlueMatt> cause there are a bunch there
19:41:16 <provoostenator> Right, that would involve branching off of the 0.17.0.1 tag and get weird.
19:41:19 <wumpus> .z releases are really 'oops we did a release and need to fix this thing up'
19:41:20 <BlueMatt> but, at least IMO, its super annoying that you cant build+run bitcoin-qt on the now-several-months-old versions of various OSs, and I presume other rolling distros (eg arch) also have this issue
19:41:24 <wumpus> not for month later
19:41:33 <instagibbs> I keep crashing, get 14380 in please ;P
19:41:50 <BlueMatt> so I would prefer we not wait around for fixing getbalance :p
19:41:56 <wumpus> I agree with BlueMatt on this
19:42:05 <BlueMatt> #14380 looks more than merge-able from where I'm sitting in the ack department
19:42:08 <gribble> https://github.com/bitcoin/bitcoin/issues/14380 | fix assert crash when specified change output spend size is unknown by instagibbs · Pull Request #14380 · bitcoin/bitcoin · GitHub
19:42:13 <BlueMatt> and not too hard to backport
19:42:44 <sipa> can people have a look at #14780 too?
19:42:46 <gribble> https://github.com/bitcoin/bitcoin/issues/14780 | PSBT backports to 0.17 by sipa · Pull Request #14780 · bitcoin/bitcoin · GitHub
19:42:59 <sipa> (i'm mostly unfamiliar with the backports process)
19:43:01 <wumpus> there is no agreement on getbalance yet, it can wait for 0.17.2
19:43:07 <wumpus> sipa: sure!
19:43:14 <sipa> thanks
19:43:59 <wumpus> sipa: please make sure you include the commit metadata (Github-Pull: #.... and Rebased-From: <commit>)
19:44:10 <BlueMatt> next topic: the wall of text I just posted to bitcoin-dev :p
19:44:13 <wumpus> (see the commits in other backport PRs such as https://github.com/bitcoin/bitcoin/pull/14835)
19:44:32 <sipa> BlueMatt: not there
19:44:34 <wumpus> next topic is moneyball's
19:44:41 <moneyball> hi
19:44:41 <BlueMatt> err, topic suggestion
19:44:50 <BlueMatt> anything else on 0.17.1?
19:45:01 <BlueMatt> or just generally a "lets take things that we can merge today, do backports, and get this thing going"
19:45:04 <provoostenator> BlueMatt: "IRC logs have been disabled due to the EU General Data Protection Regulation (GDPR)."
19:45:16 <wumpus> BlueMatt: +1
19:45:37 <provoostenator> +1
19:45:57 <wumpus> #topic proposed meeting topics ahead of time (moneyball)
19:46:02 <moneyball> I’d like to suggest that people can propose Core weekly meeting topics anytime throughout the week in this IRC channel using #proposedmeetingtopic tag. I will collect these throughout the week, add them to a gist that anyone can have a look at during the week. The primary intended benefit of this is to allow people to know which topics are going to be discussed ahead of time allowing them to prepare.
19:46:26 <moneyball> Any concerns?
19:46:31 <BlueMatt> seems reasonable
19:46:36 <provoostenator> +1
19:46:38 <BlueMatt> easier than remembering to mention them in meeting
19:46:42 <Chris_Stewart_5> +1
19:46:46 <meshcollider> +1
19:46:52 <BlueMatt> next topic? #thatwaseasy
19:47:03 <wumpus> yes, good idea, let's see how it goes
19:47:08 <moneyball> Ok I will start doing it!
19:47:15 <wumpus> BlueMatt: ok what was your proposal, I'm not in #bitcoin-dev
19:47:22 <provoostenator> And there's no logs..
19:47:32 <BlueMatt> oh, i meant bitcoin-dev ml but it hasnt passed moderation yet
19:47:36 <BlueMatt> anyway, I can tl;dr it in two lines
19:47:53 <BlueMatt> in lightning (and other related payment channel-y systems) you have the general issue of pre-signing transactions
19:48:06 <BlueMatt> so you have to predict what the feerate on the network will be in the future at the time your counterparty misbehaves
19:48:09 <wumpus> #topic pre-signing transactions (BlueMatt)
19:48:09 <BlueMatt> this is....obviously insane
19:48:18 <BlueMatt> instead, we'd (obviously) like to use cpfp
19:48:38 <BlueMatt> but there are the cpfp rbf-pinning-ish issues where your counterparty can fill up the package with big-bug-low-ish-feerate txn
19:48:43 <BlueMatt> so that you cant cpfp it yourself
19:49:03 <BlueMatt> I'd like to propose we tweak the cpfp/rbf rules
19:49:04 <BlueMatt> The last transaction which is added to a package of dependent transactions in the mempool must:
19:49:04 <BlueMatt> * Have no more than one unconfirmed parent,
19:49:04 <BlueMatt> * Be of size no greater than 1K in virtual size.
19:49:25 <BlueMatt> (we'd, in practice, first decrease the package size limits by 1 1K-virtual-size transaction, then make it so that the last one must meet those rules)
19:49:47 <BlueMatt> this allows for cpfp by letting each side of a lightning channel independantly cpfp without considering what the other side may be doing
19:49:48 <provoostenator> Current RBF rules for reference: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#Implementation_Details
19:50:08 <BlueMatt> that may be too much to think about before reading the full ml post, but mostly it just covers background material
19:50:18 <BlueMatt> /fin
19:50:37 <BlueMatt> (oh, also this fix requires package relay, which is another can of worms itself)
19:50:40 <sipa> here is another earlier proposed modification: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html
19:50:47 <sipa> BlueMatt: oh dear
19:51:16 <BlueMatt> well, luckily only one-deep package relay and only for small-ish packages
19:51:19 <BlueMatt> or at least small dependents
19:51:48 <instagibbs> sorry how does cpfp get pinned again?
19:51:57 <instagibbs> RBF pinning I know
19:52:05 <BlueMatt> instagibbs: A -> B where B is 100KB but low feerate, but high fee. its the same issue for lightning
19:52:11 <BlueMatt> cause you cant add to the package cause the package is max size
19:52:22 <instagibbs> ah
19:52:33 <sipa> my response to this is "eh... sure.... but how?"
19:52:34 <instagibbs> so it's not something you can attach B'
19:52:36 <BlueMatt> so you have to add to the package by rbf which means you have to increase total size, if you can even do that, which you'd have to tweak rbf rules to let you replace B with C, but you cant do that today
19:52:46 <BlueMatt> sipa: hmm?
19:52:52 <sipa> you need package relay...
19:53:17 <sipa> that's not just a small few-lines policy change
19:53:19 <provoostenator> An alternative, I forgot what the problem was, is to drop RBF rule "3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." and only consider fee rate of the replacement, regardless of size.
19:53:23 <sdaftuar> so i think package relay is a whole other topic
19:53:27 <BlueMatt> I have another bitcoin-dev post coming discussing package relay, but we have a few options there, if we just want to solve package relay for contracting applications like lightning, we can do so with limited consideration, I think
19:53:48 <BlueMatt> if we want a more general solution I still think its possible but requires more in-depth ATMP refactoring
19:54:00 <sipa> and P2P changes...
19:54:05 <BlueMatt> assuming we do at least one of those two, this is a simple (I think) policy change that I'm hoping people here dont object to
19:54:15 <BlueMatt> possibly, though actaully not neccessarily
19:54:21 <BlueMatt> but, probably
19:54:34 <sipa> this sounds very preliminary to me
19:54:48 <BlueMatt> i presume you mean the package relay part?
19:54:59 <BlueMatt> the policy rule here is pretty straightforward, I think?
19:55:06 <BlueMatt> and not very preliminary, again assuming some form of package relay
19:55:32 <sipa> i don't understand how you can say it's not preliminary, while relying on something we have no idea about yet
19:55:49 <meshcollider> Shall we discuss next week instead after reading the ml
19:55:50 <gmaxwell> MAGIC
19:55:55 <BlueMatt> heh, sdaftuar and I have been batting package relay back and forth for months, but, whatever
19:56:03 <BlueMatt> agreed we need a harder proposal for package relay
19:56:11 <sdaftuar> well i think it'd be useful to layout the design goals for a package relay ssytem
19:56:12 <BlueMatt> anyway, yes, we'll discuss package relay on the ml and then come back to this
19:56:13 <sipa> BlueMatt: yes i'd like to see a proposal for that :)
19:56:16 <gmaxwell> BlueMatt: the point is that the policy change justification is a black box to us for the moment. :P
19:56:20 <BlueMatt> also what sdaftuar said
19:56:28 <BlueMatt> this is also a motivator for package relay
19:56:36 <BlueMatt> as its yet another thing to feed into the design goals
19:56:57 <BlueMatt> gmaxwell: I mean if you presume package relay it isnt at all a black box?
19:56:58 <BlueMatt> huh
19:57:05 <BlueMatt> anyway, -> ml
19:57:06 <provoostenator> Topic suggestion: dandelion stempool relay :-P
19:57:14 * sdaftuar hides
19:57:14 <BlueMatt> 4 minutes, GO
19:57:19 <BlueMatt> err, 3
19:57:27 <instagibbs> sdaftuar, you ahve 3 minutes to resolve it
19:58:19 <wumpus> #topic wallet maintainer
19:58:42 <wumpus> meshcollider has shown interest in becoming wallet maintainer!
19:59:01 <provoostenator> Awesome
19:59:03 * sipa offers condolences
19:59:12 <sipa> :)
19:59:21 <provoostenator> Anyoe against, no, done. End meeting :-)
19:59:31 <wumpus> which is great news, I think he'd be good at his, many of his his contributions have been to the wallet
19:59:33 <meshcollider> :)
19:59:59 <wumpus> and he's been active contributor for quite a while
20:00:00 <sipa> more seriously, sounds great to me
20:00:05 <achow101> +1
20:00:05 <wumpus> yes!
20:00:27 <bitcoin-git> [13bitcoin] 15vim88 opened pull request #14846: Docs: Adds development guidelines about Scripts shebang to developer-notes.md. (06master...06add_scripts_development_guidelines) 02https://github.com/bitcoin/bitcoin/pull/14846
20:00:41 <wumpus> ok, that was a quick topic, was intending to bring it up sooner but BlueMatt kind of ninja'd it :)
20:00:46 <wumpus> #endmeeting