19:00:18 <achow101> #startmeeting 
19:00:18 <core-meetingbot`> Meeting started Fri Feb 11 19:00:18 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:18 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:29 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos Murch nehan NicolasDorier paveljanik
19:00:29 <achow101> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar S3RK sipa vasild
19:00:43 <Murch> Hi
19:01:12 <achow101> there are no pre-proposed topics, anyone have anything to discuss?
19:02:15 <S3RK> hi
19:02:42 <S3RK> I'm working on the test cases for bnb without limit
19:03:51 <S3RK> was able to reproduce a case when it dropped >250k sats
19:04:19 <Murch> Ouch!
19:04:19 <achow101> are you able to run simulations?
19:04:47 <S3RK> my laptop is too slow for the simulations that you run
19:04:49 <Murch> #proposedwalletmeetingtopic Better name for `sweepwallet` RPC
19:05:48 <achow101> S3RK: that's unfortunate
19:06:01 <Murch> S3RK: How would you propose to curb such high amounts?
19:06:21 <Murch> Random Selection doesn't necessarily get a better result, although with that sort of amount it should be extremely likely
19:06:38 <Murch> I guess Knapsack should also get something with a lower waste
19:07:04 <S3RK> the worst case is when knapsack latches onto an exact match with many inputs
19:07:39 <S3RK> and due to sheer amount of inputs in the wallet SRD can't find predictably a good solution either
19:08:00 <S3RK> i have two ideas 1) keep the limit but move it higher
19:08:30 <S3RK> 2) introduce another selection algo in the mix that will find solution in such cases
19:08:52 <S3RK> #1 is pretty easy, I'll do a bit more research on what is a good value for the limit
19:08:54 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
19:09:00 <S3RK> lol
19:10:03 <achow101> I think another algo is going to be more difficult than finding a better limit
19:10:23 <Murch> Well, in what way?
19:10:24 <S3RK> the thing is even with higher limit the selection in such scenario is pretty bad
19:10:37 <S3RK> the waste is huuuge
19:10:48 <Murch> Yeah
19:10:59 <S3RK> and it's kind of obvious what is the optimal solution
19:11:26 <Murch> S3RK: Obvious in a way that can be formalized? ;)
19:11:28 <S3RK> I'll polish the test and make PR, would be easier to discuss on examples
19:11:30 <michaelfolkson> hi
19:11:34 <glozow> hi
19:11:44 <Murch> oh, you mean for the higher limit?
19:12:12 <S3RK> murch: not sure about formalization
19:13:09 <jonatack> hi (wallet meeting started ten minutes ago or is it at the top of the next hour?)
19:13:11 <S3RK> I think an algo minimizing the fees would find it
19:13:32 <Murch> jonatack: it's on-going
19:13:41 <jonatack> Murch: ty
19:13:54 <achow101> S3RK: yes, examples would be useful
19:14:05 <Murch> or just LF
19:14:05 <Murch> S3RK: Oh, sure. But that would essentially boil down to smallest input larger than the target
19:14:13 <bitcoin-git> [bitcoin] dongcarl opened pull request #24322: [kernel 1/n] Introduce initial `libbitcoinkernel` (master...2022-02-libbitcoinkernel-p1-minimal) https://github.com/bitcoin/bitcoin/pull/24322
19:14:21 <Murch> For a single selection that's of course optimal
19:14:31 <Murch> It's probably not optimal for the long-term, though
19:14:51 <S3RK> not always, because consolidation could be better if fees are low
19:14:59 <S3RK> but I understand the challenge
19:15:09 <S3RK> maybe we can punish such solutions by some fixed waster
19:15:10 <S3RK> idk
19:15:13 <Murch> Right, but that wouldn't be minimizing fees
19:15:26 <Murch> But rather minimizing waste :)
19:15:41 <Murch> mh.
19:15:58 <S3RK> well... I mean the algo searches for the minimum fee solution
19:16:05 <S3RK> but the final result is selected by waste
19:16:11 <Murch> ah yes
19:16:18 <S3RK> which means that the algo won't always win
19:16:47 <Murch> Right, but it would also mean that we would usually get a single input solution for anything above 10 sat/vB
19:17:06 <S3RK> I agree it might skew the selection too much. just an idea
19:17:10 <Murch> Occasionally, maybe a BnB solution with two inputs that has better waste
19:17:42 <Murch> Yeha, sorry, I'm not trying to dissuade brain storming
19:18:09 <Murch> I was just considering it as well, but I think it would basically get rid of almost all other solutions
19:18:24 <Murch> (for the high feerate case, that is)
19:18:28 <S3RK> oh! what if we do run knapsack with a few change targets?
19:18:57 <S3RK> the problem now is that if there is an exact match knapsack quits
19:19:00 <achow101> I thought we were plannin on ditching knapsack
19:19:45 <S3RK> I'm not sure SRD + bnb only cover all cases, like the one we are dicussing no
19:19:58 <Murch> achow101: Yeah, but isn't it currently providing something like 60% of all selection solutions? We should probably find something that beats Knapsack before getting rid of it
19:21:03 <Murch> I don't like how computationally inefficient it is, but it currently seems to be the best solution per waste metric most of the time
19:22:08 <Murch> mh. If there is an exact match, we should also find it with BnB.
19:22:32 <Murch> Perhaps we could just kick that out of Knapsack's terminal conditions?
19:22:33 <S3RK> we do, but the waste sucks. and BnB preffers to drop 250k sats to fees
19:23:14 <Murch> Oh, you mean in the case that we get an input set with tons of inputs
19:23:20 <S3RK> yes
19:23:29 <Murch> Well, that would be more of a bug than intended behavior, wouldn't it?
19:23:44 <achow101> if I understand correctly, both bnb without limit and knapsack find solutions that suck, when there is a better one?
19:23:54 <S3RK> indeed
19:24:00 <S3RK> the scenario is like this
19:24:01 <achow101> for some definition of better that doesn't quite include waste?
19:24:22 <S3RK> we have one big coin and tons of small ones
19:24:51 <S3RK> we send an amount that is exact match of 100 small coins AND just under big coin
19:24:54 <Murch> Isn't it more like "BnB without limit finds always a solution, but they suck sometimes"?
19:25:16 <S3RK> bnb without limit finds a solution when we use one big coin and drop the rest for fees
19:25:25 <S3RK> knapsack finds exact match which is bad
19:25:44 <S3RK> the optimal is to take one big coin + maybe a few small and create change
19:25:50 <achow101> hmm, maybe we need a knapsack replacement that doesn't do exact match
19:26:07 <S3RK> SRD could find it, but if there are tons of coins that the chances are not in our favor
19:26:28 <Murch> Right
19:26:32 <Murch> Makes sense
19:27:03 <achow101> knapsack also does a couple different things, perhaps we should split it up. e.g. the "lowest larger" part of it sounds like it would solve this problem
19:27:06 <Murch> Has any of you ever looked into the "blackjack" algo?
19:27:39 <S3RK> Murch saying just having lowet larger would skew selection too much
19:27:54 <S3RK> didn't look into "blakjack" algo
19:28:19 <Murch> achow101: lowest larger would probably almost always win the waste metric for high feerate cases
19:28:32 <S3RK> but what about running knapsack (or any other algo which optimizes for amount match) two times
19:28:44 <S3RK> one time with the target amount and another with that + some change target
19:28:53 <Murch> So it would highly favor short term optimal solutions but encourage fragmentation of the wallet in the long run
19:29:02 <S3RK> (stupid me, this doesn't help)
19:29:12 <achow101> Murch: what about lowest larger without a change target?
19:29:23 <achow101> (i.e. burn the excess)
19:29:32 <S3RK> that's bnb-without-limit
19:29:56 <Murch> Blackjack in a couple sentences: continuously pick the largest coin smaller than the missing amount. When no such coin exists, add smallest larger
19:30:29 <Murch> So, it'll always pick a few inputs, but in the end will always find a solution
19:30:50 <S3RK> will it find solution in the scenario I described above?
19:30:54 <S3RK> sounds like no
19:30:56 <Murch> It should also be somewhat consolidatory at low feerates
19:31:06 <Murch> mhh.
19:31:17 <Murch> S3RK: Ugh, you're right
19:31:46 <Murch> Maybe if you limit the first part to ~5 or ten inputs
19:31:46 <achow101> I'm slightly confused. I think I need to look at an actual input set
19:32:04 <S3RK> yes, it's difficult to keep in the head
19:32:13 <achow101> need a whiteboard :)
19:32:19 <S3RK> I'll do a PR once I clean up the code
19:32:27 <S3RK> helped me a lot to reason about it
19:33:00 <S3RK> that's all from me
19:33:09 <achow101> ok, I'll wait for that
19:33:29 <Murch> achow101: You have 100× 1 m₿ and 1× 102.5 m₿. Select for 100 m₿
19:34:11 <achow101> #topic Better name for `sweepwallet` RPC (Murch)
19:34:11 <core-meetingbot`> topic: Better name for `sweepwallet` RPC (Murch)
19:34:24 <Murch> Okay
19:35:17 <Murch> Well, the proposed RPC was first named `sweep`, and multiple people said that their first instinct was that its function was to take the funds from an external privKey and send the funds into the wallet
19:35:50 <Murch> So we renamed it to `sweepwallet` thinking that this would distinguish it, but the comment has come up again :)
19:36:36 <Murch> So, I'm open for people proposing a better name for an RPC that has the function of:
19:36:36 <Murch> • Take a set of UTXOs and send all of it to a recipient deducting fees
19:36:53 <S3RK> sendcoind/sendutxos?
19:37:05 <achow101> I think sweepwallet is fine
19:37:16 <S3RK> sweepwallet is also fine with me fwiw
19:38:12 <Murch> Mh. `sendcoins` does kinda work for me
19:38:35 <Murch> Anyway, I don't want to dwell on it too much. If people have ideas, please dm me, or post on the PR.
19:39:01 <Murch> If we don't come up with something much better, I'd just stick with it, though
19:40:03 <Murch> That's #24118 I'm talking about, btw
19:40:03 <achow101> anything else to discuss?
19:40:05 <gribble> https://github.com/bitcoin/bitcoin/issues/24118 | Add sweepwallet RPC by Xekyo · Pull Request #24118 · bitcoin/bitcoin · GitHub
19:40:16 <Murch> That's it from me
19:41:08 <achow101> #endmeeting