19:00:04 <laanwj> #startmeeting 
19:00:04 <core-meetingbot`> Meeting started Thu Feb  3 19:00:04 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:04 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:20 <dongcarl> hello
19:00:22 <laanwj> #bitcoin -core-dev 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
19:00:23 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:27 <jonatack> hi
19:00:27 <provoostenator> hi
19:00:29 <hebasto> hi
19:00:35 <achow101> hi
19:00:38 <sipa> hi
19:00:51 <laanwj> there have been no proposed meeting topics this week (this can be done using #proposedmeetingtopic <topic>), any last-minute ones?
19:00:56 <michaelfolkson> hi
19:01:27 <MarcoFalke> hi
19:01:44 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #24253:  Remove broken and unused CDataStream methods  (master...2202-s) https://github.com/bitcoin/bitcoin/pull/24253
19:02:32 <cfields> hi
19:03:28 <warren> hi
19:03:39 <laanwj> PSA: today the string freeze for 0.23 started, after #24250 is merged i'll open the translations
19:03:41 <gribble> https://github.com/bitcoin/bitcoin/issues/24250 | Update translations for 0.23 string freeze by laanwj · Pull Request #24250 · bitcoin/bitcoin · GitHub
19:03:43 <jeremyrubin> Gm
19:04:03 <laanwj> #topic High priority for review
19:04:03 <core-meetingbot`> topic: High priority for review
19:04:19 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 -- only 6 blockers left
19:04:32 <kanzure> hi
19:04:34 <b10c> hi
19:04:42 <sipa> i'd like to suggest #23542 for high priority (or really, for trying to get it in v23)
19:04:44 <gribble> https://github.com/bitcoin/bitcoin/issues/23542 | net: open p2p connections to nodes that listen on non-default ports by vasild · Pull Request #23542 · bitcoin/bitcoin · GitHub
19:05:32 <laanwj> sipa: added (and added 23.0 milestone)
19:05:39 <sipa> Thanks!
19:05:50 <jonatack> #23604 has 4 acks
19:05:53 <gribble> https://github.com/bitcoin/bitcoin/issues/23604 | Use Sock in CNode by vasild · Pull Request #23604 · bitcoin/bitcoin · GitHub
19:06:30 <jonatack> sipa: +1
19:06:36 <laanwj> jonatack: great!
19:07:03 <laanwj> anything else to add, remove or that is (almost) ready for merge?
19:09:04 <laanwj> the boost::filesystem removal was merged today, i'd recommend testing the current master branch on as many platforms and operating systems as you can to make sure any issues come to light
19:09:16 <sipa> Good idea.
19:09:27 <warren> That was the last boost dependency?
19:09:32 <laanwj> i don't expect anything but you never know!
19:09:48 <michaelfolkson> Presumably #22558 shouldn't get 23.0 milestone? Not much review yet
19:09:49 <gribble> https://github.com/bitcoin/bitcoin/issues/22558 | psbt: Taproot fields for PSBT by achow101 · Pull Request #22558 · bitcoin/bitcoin · GitHub
19:10:15 <michaelfolkson> Would be nice to get some Taproot stuff in 23.0 but obviously needs review
19:10:15 <laanwj> warren: there's still signals2, which is quite easy to replace, and boost::multi_index, which is not
19:10:27 <sipa> warren: We have lots of boost dependencies still, but most are headers-only
19:10:29 <sipa> or all?
19:10:41 <warren> Is it a goal to get rid of boost eventually?
19:10:43 <laanwj> sipa: afaik yes
19:10:52 <hebasto> all are headers only except for Boost.Test
19:10:57 <sipa> warren: I don't care about getting rid of headers-only ones.
19:11:02 <luke-jr> no
19:11:07 <sipa> They're just a build-time dependency.
19:11:07 <laanwj> ah yes, boost::test, didn't count that one as it's test only
19:11:38 <laanwj> right, there's no real hurry, though signals2 is kinda ugly due to the enormous backtraces it generates
19:11:56 <sipa> boost::multi_index in particular would be a major engineering challenge to replace with anything similar in functionality
19:12:15 <laanwj> yeah... might just import that one :)
19:12:32 <MarcoFalke> Someone should shepherd multi_index into C++26
19:12:46 <laanwj> in any case, it's fine, would be good if it was behind a pimpl though so it didn't get imported into every other file
19:13:08 <laanwj> MarcoFalke: yea!
19:13:13 <sipa> right
19:14:25 <laanwj> michaelfolkson: not sure really, if it makes 23.0 it makes 23.0, but i'm not sure it makes sense to specialy label it for that
19:14:47 <jonatack> could #24165 be tagged for v23?
19:14:48 <gribble> https://github.com/bitcoin/bitcoin/issues/24165 | p2p: extend inbound eviction protection by network to CJDNS peers by jonatack · Pull Request #24165 · bitcoin/bitcoin · GitHub
19:15:18 <jonatack> vasild and i are coordinating to propose a doc/cjdns.md for v23 as well
19:15:27 <sipa> cool
19:15:28 <laanwj> if it's unlikely to make it, it shouldn't be added to the milestone, generally nothing but critical fixes actually blocks a release anyway
19:15:33 <laanwj> jonatack: will do
19:15:56 <jonatack> thanks!
19:16:58 <laanwj> jonatack: concept ACK, though, should keep it compact imo, i don't think we should end up with extensive documentation about setting up all kind of overlay network in our repo
19:17:48 <laanwj> granted, tor.md is pretty big but that's mainly because we have a lot of configurability related to tor
19:18:19 <jonatack> laanwj: yes. the main thing people seem to trip up on when getting started is the find a friend part (myself included).
19:18:33 <laanwj> jonatack: yes, that's always the difficult part :)
19:19:03 <Murch> #proposedmeetingtopic sweep vs subtract-fee-from-output
19:19:04 <laanwj> i hope cjdns.md will help some people find friends :p
19:19:15 <jonatack> :)))
19:19:21 <sipa> Murch: For this meeting, or wallet meeting?
19:20:20 <michaelfolkson> Has to wait a week if it is wallet meeting :)
19:20:56 <Murch> Pieter: If this meeting runs out of topics, I'd be happy to talk about it here, but otherwise wallet meeting is fine, too.
19:21:11 <laanwj> we're out of topic right now, so, happy to take it
19:21:19 <Murch> Okay
19:21:21 <laanwj> #topic sweep vs subtract-fee-from-output (Murch)
19:21:21 <core-meetingbot`> topic: sweep vs subtract-fee-from-output (Murch)
19:21:41 <warren> summary writeup of this anywhere?
19:21:55 <Murch> achow101 and I have been looking into implementing a Sweep RPC in https://github.com/bitcoin/bitcoin/pull/24118
19:22:38 <Murch> The main motivation is that SFFO creates a bunch of issues for coin selection and makes testing more complex
19:23:05 <Murch> Our impression was that the main use case for SFFO was to perform sweeps and to spend the full balance of wallet
19:23:28 <Murch> This was at least the cited reasons in #4331 when it was proposed.
19:23:30 <gribble> https://github.com/bitcoin/bitcoin/issues/4331 | Subtract fee from amount by cozz · Pull Request #4331 · bitcoin/bitcoin · GitHub
19:23:44 <laanwj> it's useful for sending entire utxos to another wallet
19:24:09 <Murch> laanwj: We intend for sweep to also allow specifying input UTXOs
19:24:25 <Murch> It's not in the current iteration, but something we want to do in a follow-up
19:24:38 <laanwj> i've used it pretty often and never for sweeps
19:24:50 <jeremyrubin> very much supportive of sweep and getting rid of SFFO; generally speaking if i am trying to pay someone 10000 sats and they get 9999, that might not be a valid payment anymore. SFFO seems like a huge footgun.
19:24:58 <laanwj> the target might not be a bitcoin core wallet (e.g. c-lightning, joinmarket, etc)
19:25:07 <provoostenator> We could call it "sendcoins" instead of sweep, but potato potato
19:25:17 <warren> I've used SFFO often to selectively combine only specific UTXO's where I don't want change outputs. It seems strange if that's taken away.
19:25:21 <laanwj> it's not useful for sending to other people, agree
19:25:23 <Murch> laanwj: Could you describe the use case that leads to an SFFO payment?
19:25:31 <Murch> We've been trying to figure out what people use it for.
19:25:45 <laanwj> Murch: coinjoin, sending an entire utxo without generating an extra change input
19:25:57 <laanwj> or combining a bunch of utxos
19:26:05 <provoostenator> Murch: sending 1 UTXO to an exchange
19:26:20 <laanwj> it's good for privacy generally to not generate change
19:26:25 <Murch> laanwj: So if you could specify a set of UTXOs in sweep, that seems to be covered
19:26:32 <laanwj> especially if your utxos are already not linked
19:26:32 <provoostenator> And to not combine coins from different source
19:26:37 <laanwj> right
19:26:52 <jeremyrubin> laanwj: altho not generating change is also a privacy leak itself
19:27:06 <laanwj> jeremyrubin: it's kind of subtle
19:27:11 <Murch> jeremyrubin: Not when you have multiple recipients. ;)
19:27:27 <laanwj> Murch: can you sweep to another address or set of addresses?
19:27:33 <jeremyrubin> laanwj: if you're one of the only people in the world with this pattern rn, i may be able to find you ;)
19:28:01 <sipa> using SFFO to construct the spending of specific UTXOs without change is kind of a roundabout way of doing it... it's essentially trying to trick the coin selection into doing what you want, rather that just not doing coin selection at all
19:28:08 <provoostenator> jeremyrubin: that's what on chain dobbelgangers are for, I'm sure you can hire those.
19:28:09 <Murch> laanwj: Yes, the rpc takes multiple addresses of which at least one must not specify an amount and gets the remainder. If multiple are unspecified, it splits equally.
19:28:12 <laanwj> jeremyrubin: sigh, sure, we can't really talk about use-cases here and this whole discussion is moot
19:29:04 <warren> Several users I recruited over the years use SFFO with multiple outputs to obscure which output is payment further making the amounts sent not round numbers. But I've personally used it to avoid creating change outputs when sending to myself or to other people were exact amounts don't matter or they're willing to eat the tx fee as part of the bargain.
19:29:10 <jeremyrubin> laanwj: didn't mean to badger you, just a reminder that 'good for privacy' depends on the behavior being widespread generating anonymity set.
19:29:39 <Murch> Another use case we've gotten feedback about on Twitter was that you "can make the receiver pay the fees". This seems like a roundabout way of making the receiver take a risk on how large a transaction is going to be, and would imho be better implemented by deducting a flat amount.
19:30:12 <provoostenator> I don't have strong feelings about what it should look like under the hood.  But the current manual coin selection GUI works fine for it.
19:30:16 <prayank> This was the thread: https://nitter.net/achow101/status/1488624425285079048
19:30:23 <laanwj> in any case, i do like the sffo functionality, and would be sad to see it go
19:30:34 <laanwj> roundabout way or not
19:30:44 <provoostenator> Murch: or just setting the fee to 1 sat/byte?
19:30:46 <Murch> Mh, okay, noted.
19:30:55 <laanwj> i'm fine if it only works with manual coin control
19:31:01 <_aj_> maybe don't deprecate until the "specifying input UTXOs" part is done?
19:31:02 <warren> +1 provoostenator I like the current coin control GUI and option for SFFO I use almost always. How it works under the hood is a different matter.
19:31:04 <Murch> provoostenator: I'm not sure I follow
19:31:09 <laanwj> and skips coin selection
19:31:19 <sipa> _aj_: I'd assume that'd be the case
19:31:30 <jonatack> if SFFO includes the subtractfeefromamount option in RPCs like sendtoaddress, i find it useful when someone wants to buy btc, sets the feerate, and pays the fee
19:31:35 <provoostenator> Murch: if the recipient wants to CPFP you can just use a low fee rate
19:31:35 <laanwj> warren: right-i suspect it's pretty much  always used with manual coin control
19:31:55 <jeremyrubin> laanwj: what about just being able to generate a transaction automatically and then modify it to deduct the fees manually from the outputs you want to deduct?
19:31:57 <Murch> provoostenator: That requires sending a second transaction, though.
19:32:05 <_aj_> #24142 
19:32:06 <gribble> https://github.com/bitcoin/bitcoin/issues/24142 | Deprecate SubtractFeeFromOutputs by achow101 · Pull Request #24142 · bitcoin/bitcoin · GitHub
19:32:29 <laanwj> jeremyrubin: i like it's user friendly and easy to use now
19:32:30 <provoostenator> Indeed  limiting it to manual coin selection would be fine by me too
19:32:45 <provoostenator> So basically if you select any coins, we don't auto select more.
19:32:54 <warren> +1
19:32:55 <achow101> apparently bull bitcoin (an exchange) uses sffo to make their users pay the fee if they want to opt out of batched transactions. limiting to manual would break that use case
19:33:00 <laanwj> sure, i know how to make manual transactions and subtract fee etc, but having to compute things manually sucks compared to just using the interface
19:33:06 <cfields> +1
19:33:10 <jonatack> +1
19:33:27 <provoostenator> achow101: Murch: oh now it makes sense
19:33:32 <jeremyrubin> i think subtracting fees could be done in a user friendly
19:33:45 <cfields> jeremyrubin: Indeed I've done that several times.
19:33:50 <jeremyrubin> like 10 - x works in e.g. GIMP
19:33:58 <jeremyrubin> (for computing pixels or whatever)
19:33:59 <provoostenator> So they're "paying" by just lowering the amount they receive?
19:34:25 <laanwj> it's clearly controversial to remove this functionality
19:35:02 <achow101> indeed
19:35:03 <laanwj> not arguing against adding a sweep RPC, but i think proposing it to replace sffo is getting ahead of things
19:35:10 <warren> +1
19:35:20 <Murch> Right, thanks for the feedback!
19:35:34 <achow101> i guess we need to unbreak sffo first
19:36:01 <Murch> Indeed
19:36:24 <Murch> Alright, this was very helpful (even if not the outcome I was hoping for 0:-))
19:38:17 <laanwj> any other topics?
19:39:47 <laanwj> looks like not, thanks for attending, closing the meeting
19:39:50 <laanwj> #endmeeting