--- Log opened Thu Nov 30 00:00:41 2023
00:14 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
00:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
00:45 -!- salvatoshi [~salvatosh@194.65.48.125] has joined #bitcoin-core-dev
00:48 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
00:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
01:10 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:15 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
01:31 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:32 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
01:46 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
01:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
02:19 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
02:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
02:26 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
02:52 -!- Guest47 [~Guest47@2603-9001-1700-3915-30c0-2bf5-446f-7068.inf6.spectrum.com] has joined #bitcoin-core-dev
02:53 -!- Guyver2_ [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
02:56 -!- Guest47 [~Guest47@2603-9001-1700-3915-30c0-2bf5-446f-7068.inf6.spectrum.com] has quit [Client Quit]
03:01 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
03:01 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
03:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
03:24 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
03:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
03:28 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
03:36 -!- boris- [~boris@201.189.64.198] has quit [Quit: ZNC 1.8.2 - https://znc.in]
03:57 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
04:02 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
04:07 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
04:08 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
04:13 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
04:16 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 240 seconds]
04:18 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
04:47 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
04:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
04:53 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
05:03 -!- darosior6 [~darosior@109.205.214.46] has joined #bitcoin-core-dev
05:03 -!- darosior [~darosior@109.205.214.46] has quit [Read error: Connection reset by peer]
05:03 -!- darosior6 is now known as darosior
05:33 < glozow> instagibbs: right, I think EA anchor without its child should be removed from mempool, yes? (it’s always 0fee iirc so 27018 should suffice?)
05:37 -!- kashifs [~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com] has joined #bitcoin-core-dev
05:39 < bitcoin-git> [bitcoin] maflcko opened pull request #28972: test: Add and use option for tx-version in MiniWallet methods (master...2311-test-mw-version-) https://github.com/bitcoin/bitcoin/pull/28972
05:54 < Sjors[m]> #proposedmeetingtopic: Stratum v2
05:54 < Sjors[m]> #proposedmeetingtopic Stratum v2
05:56 -!- guest-127 [~guest-127@212.129.84.94] has joined #bitcoin-core-dev
05:59 -!- instagibbs_ [uid142535@id-142535.tinside.irccloud.com] has joined #bitcoin-core-dev
06:00 < achow101> #startmeeting
06:00 < glozow> hi
06:00 < RubenSomsen> hi
06:00 < hebasto> hi
06:00 < murch[m]> Hi
06:00 < fjahr> hi
06:00 < achow101> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild
06:00 < Sjors[m]> hi
06:00 < brunoerg> hi
06:00 < darosior> hi
06:00 < furszy> hi
06:00 < vasild> hi
06:00 < gleb> hi
06:00 < achow101> There are 2 pre-proposed meeting topics, any last minute ones to add to the list?
06:01 < kanzure> hi
06:01 < RubenSomsen> I'll do another silent payments update
06:01 < achow101> #topic package relay updates (glozow)
06:01 < sipa> hi
06:01 < glozow> 2 PRs are open for review: #28848 and #28948.
06:01 < glozow> The game plan is in 2 tracks mempool and p2p: v3 (#28948), then package RBF for 1p1c (#25038), then EA (#26403). And 1p1c package relay (#28970), then more robust orphan resolution (#28031), then orphanage protection.
06:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/28848 | bugfix, Change up submitpackage results to return results for all transactions by instagibbs · Pull Request #28848 · bitcoin/bitcoin · GitHub
06:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow · Pull Request #28948 · bitcoin/bitcoin · GitHub
06:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow · Pull Request #28948 · bitcoin/bitcoin · GitHub
06:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/25038 | policy: nVersion=3 and Package RBF by glozow · Pull Request #25038 · bitcoin/bitcoin · GitHub
06:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/26403 | policy: Ephemeral anchors by instagibbs · Pull Request #26403 · bitcoin/bitcoin · GitHub
06:02 <@gribble> https://github.com/bitcoin/bitcoin/issues/28970 | [WIP] p2p: opportunistically accept 1-parent-1-child packages by glozow · Pull Request #28970 · bitcoin/bitcoin · GitHub
06:02 <@gribble> https://github.com/bitcoin/bitcoin/issues/28031 | Package Relay 1/3: Introduce TxDownloadManager and improve orphan-handling by glozow · Pull Request #28031 · bitcoin/bitcoin · GitHub
06:02 < theStack> hi
06:03 < _aj_> hi
06:03 < glozow> The very exciting thing is we’ll have 1p1c package relay at the end of this. And then cluster mempool!
06:03 < b10c> hi
06:04 < achow101> cool
06:04 < achow101> #topic silent payments updates (RubenSomsen)
06:05 < RubenSomsen> Still actively taking review on BIP352, responding to feedback, and wanting review on #25273.
06:05 <@gribble> https://github.com/bitcoin/bitcoin/issues/25273 | wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101 · Pull Request #25273 · bitcoin/bitcoin · GitHub
06:05 < RubenSomsen> A change we're considering in outpoint hashing (to make things simpler for hardware wallets) has an issue with forced collisions (worst case is address reuse), a possible fix is being discussed at https://github.com/bitcoin/bips/pull/1458#discussion_r1395934177
06:05 < RubenSomsen> Could use more eyes on that
06:05 < sipa> fwiw, we've been having some of our cluster mempool discussions on delving: https://delvingbitcoin.org/c/implementation/wg-cluster-mempool/9
06:06 < maxedw> hi
06:06 < murch[m]> Nice to see the discussion accessible in public!
06:07 < achow101> #topic multiprocess updates (ryanofsky)
06:08 -!- Murch [~Murch@user/murch] has joined #bitcoin-core-dev
06:09 < achow101> looks like the tracking issue was updated and several new PRs have been opened
06:09 < achow101> #28921 seems to be next
06:09 <@gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky · Pull Request #28921 · bitcoin/bitcoin · GitHub
06:09 < ryanofsky> Hi, yes there are a few new prs opened
06:10 < ryanofsky> Currently working on a design doc which I want to post in a new PR this week
06:10 < ryanofsky> Tracking issue is https://github.com/bitcoin/bitcoin/issues/28722 if anyone is looking what to review
06:11 < achow101> #topic Ad-hoc high priority for review
06:12 < achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
06:12 < gleb> can you add #28765?
06:12 <@gribble> https://github.com/bitcoin/bitcoin/issues/28765 | p2p: Fill reconciliation sets (Erlay) by naumenkogs · Pull Request #28765 · bitcoin/bitcoin · GitHub
06:13 < achow101> gleb: added
06:13 < gleb> thanks
06:13 < _aj_> #27432 has concept acks, could be dropped from there, presumably?
06:14 <@gribble> https://github.com/bitcoin/bitcoin/issues/27432 | contrib: add tool to convert compact-serialized UTXO set to SQLite database by theStack · Pull Request #27432 · bitcoin/bitcoin · GitHub
06:14 < maflcko> Can I have #28924 ? (It is a blocker for a bugfix)
06:14 <@gribble> https://github.com/bitcoin/bitcoin/issues/28924 | refactor: Remove unused and fragile string interface from arith_uint256 by maflcko · Pull Request #28924 · bitcoin/bitcoin · GitHub
06:14 < hebasto> #26762 seems almost rtm?
06:14 <@gribble> https://github.com/bitcoin/bitcoin/issues/26762 | bugfix: Make `CCheckQueue` RAII-styled (attempt 2) by hebasto · Pull Request #26762 · bitcoin/bitcoin · GitHub
06:14 < achow101> _aj_: maflcko: done
06:14 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds]
06:15 < maflcko> thanks 
06:15 < theStack> can i have #28336 added?
06:15 <@gribble> https://github.com/bitcoin/bitcoin/issues/28336 | rpc: parse legacy pubkeys consistently with specific error messages by theStack · Pull Request #28336 · bitcoin/bitcoin · GitHub
06:15 < achow101> hebasto: yes, going to try to get to that soon
06:15 < murch[m]> Chasing concept acks: https://github.com/bitcoin/bitcoin/pull/27877
06:15 < hebasto> achow101: thanks
06:15 < achow101> theStack: done
06:15 < murch[m]> Also, related to my topic later
06:15 < _aj_> achow101: #28592 should be easy to review, and basically RTM
06:15 <@gribble> https://github.com/bitcoin/bitcoin/issues/28592 | p2p: Increase tx relay rate by ajtowns · Pull Request #28592 · bitcoin/bitcoin · GitHub
06:16 < achow101> murch[m]: done. _aj_: will look
06:16 < murch[m]> Thanks
06:17 < theStack> achow101: thx
06:17 -!- Murch [~Murch@user/murch] has quit [Quit: Connection closed]
06:18 < achow101> #topic Deficient coin selection behavior at high feerates (murch[m])
06:18 < murch[m]> The mempool hasn’t cleared since end of April, and generally the blockspace market has seen a lot of demand in that time.
06:19 < murch[m]> We recently had a period of time when the feerates peaked above 300 ṩ/vB, but they generally were significantly higher than usual for long stretches this year.
06:19 < instagibbs> _aj_ might be helpful to know what the potential downsides are to the PR (I have not thought about this stuff deeply)
06:19 < murch[m]> Bitcoin Core wallet currently uses three different coin selection algorithms and generates up to ~12 candidate input sets from those in the first attempt, then picks the least wasteful among those per the waste heuristic.
06:19 < _aj_> instagibbs: ie, why there's a limit at all?
06:20 < instagibbs> _aj_ 👍
06:20 < murch[m]> However, when wallets have a very large UTXO pool, it may be that even the "least wasteful" candidate set uses a ton of inputs.
06:21 < murch[m]> We recently had another user submit disbelief when their Bitcoin Core wallet used over 500 inputs at a feerate of 75 sat/vB, when they had multiple UTXOs that could have funded the transaction by itself.
06:21 < murch[m]> This wallet behavior is unexpected to users and can cause significant unnecessary cost
06:22 < murch[m]> While adding a different coin selection algorithm would be a new feature and therefore not something that we’d put out in a point release, could we please at least aim to improve this behavior by the time of the next release?
06:23 < sipa> concept ack, but the devil is in the details
06:23 < murch[m]> I have had a pull request open with #27877 since July that would minimize the weight of the input set on transactions over 30 sat/vB
06:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus · Pull Request #27877 · bitcoin/bitcoin · GitHub
06:23 < Sjors[m]> Why don't any of the three algo's come up with a more sane result?
06:24 < murch[m]> BnB doesn’t always have a solution, Knapsack optimizes for the least overshoot, i.e. minimizes the difference in satoshis between target+min_change and selection amount, and SRD is random.
06:24 < murch[m]> If you have a huge number of UTXOs, with a few large ones, BnB might strike out, and the other two just give back crap.
06:24 < murch[m]> It is by the way my opinion that Knapsack is utterly useless and should be destroyed.
06:25 < theStack> :D
06:25 < murch[m]> And especially at high feerates e.g. above 30 sat/vB or 50 sat/vB, the wallet should be more thrifty for the sake of our users’ financial outcome.
06:25 < achow101> ack CoinGrinder, ack delete knapsack :)
06:26 < sipa> Sjors[m]: there is a difficulty here, i think, because the waste metric (which we nomiminally optimize for) doesn't account for "wallet composition health" so there is a concern that having something too minimizy might actually "win" (by waste metric) too much and result in a terrible wallet utxo set over the long term
06:27 < murch[m]> Anyway, if people agree that it’s insane our wallet might use 500+ inputs above 75 sat/vB, when a single one suffices, I would appreciate if such people consider taking a look at #27877 which has been chasing concept review since July
06:27 < achow101> I'm slightly concerned that users are going to always want to use CoinGrinder since it should always produce small input sets, at the expense of grinding coins to dust
06:27 <@gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus · Pull Request #27877 · bitcoin/bitcoin · GitHub
06:27 < murch[m]> Thanks :)
06:28 < sipa> coingrinder is much better at finding small inputs, but i'm a bit concerned that if we'd always enable coingrinder, long term wallets would degrade for exame
06:28 < murch[m]> I have another idea, which would limit the input set to use 3 more inputs than the minimal necessary by iterating over a random shuffle of the UTXO pool and dropping the UTXOs with the least effective value until it has sufficient
06:29 < murch[m]> I’ll probably be opening a PR with that in the next couple weeks
06:29 < fjahr> i guess there needs to be a plan for the extreme case where we never go below 30 sat/vB again (or whatever the limit will be)
06:29 < achow101> murch[m]: have you run simulations with CoinGrinder?
06:29 < murch[m]> A very fragmented wallet would then probably end up using 3 more inputs than necessary, which would at least be a net-negative of 2 UTXOs per transaction (after accounting for the change) and it should be much simpler to review
06:30 < vasild> murch[m]: picking the one input instead of the 500 ones would create smaller/cheaper tx now, but does this not delay the usage of the 500 smaller inputs? it is inevitable, we would have to use them at some point. Plus at 80sat/vbyte maybe the best time to do that if the fee rates have been e.g. 150 sat/vbyte one week before and will be 150 one week later, e.g. 80 may be a temporary dip where it 
06:30 < vasild> is good to spend the 500 small inputs
06:30 < achow101> vasild: unfortunately we haven't figured out how to accurately predictthefuture
06:30 < murch[m]> vasild: Yes, if this point were the lowest feerate it would be good to use many, but that’s not even true across the last few weeks
06:31 < sipa> vasild: always using the largest utxo(s) necessary would result in smallest input set right now, but in the long term, grind down your wallet utxos to dust
06:31 < murch[m]> Feerates have been going below 30 sat/vB nightly, and about a month ago were below 15 sat/vB every day
06:31 < vasild> sipa: yes
06:31 < murch[m]> When the feerates are high, we should use few UTXOs, but many utxos at low feerates
06:31 < sipa> but on the other hand, at times of extremely high fee, nobody is going to want to pay for a hihe excess in input set just for some abstract long term wallet health concern - the price for it is just too high
06:32 < murch[m]> Always using largest first is a terrible strategy, as I have show with my master thesis in 2016
06:32 < vasild> my point is "high" and "low" is relative, don't bind that to actual numbers, e.g. 75 is "high", because over time 75 may become the new "low"
06:32 < murch[m]> CoinGrinder does not use largest first, it uses the input set with the least weight, and on ties prefers the one with a lower total amount
06:32 < _aj_> 500 inputs seems like a lot even when feerates are low
06:32 < instagibbs> 500 inputs is like.. we need a consolidate rpc
06:33 < sipa> vasild: we have the long-term fee estimate whose algorithm is currently "return 10 sat/vb;", but in theory, this value influences the waste metric
06:33 < _aj_> instagibbs: "sendall"
06:33 < murch[m]> vasild: Yes, you’re right in principle, but 75 sat/vB is a high feerate across the last year, including the last few months.
06:33 < sipa> vasild: coingrinder in the current PR triggers based on a multiple of the long-term feerate estimate
06:33 < instagibbs> _aj_ that is triggered by utxo health metric or something :P
06:34 < _aj_> instagibbs: "bitcoin-cli wallet-wizard" - evaluates the health of your wallet utxos, and autoconsolidates
06:34 < sipa> i think i like this "look for randomish solution not exceeding N extra inputs over optimal" idea more than coingrinder, as i don't think it needs guards like "only at high feerate"
06:35 < sipa> instagibbs: if we'd have a wallet health metric we could optimize for it directly
06:35 < murch[m]> Yeah, we can bikeshed over the exact strategy later, I mainly just would like to see if people agree that people unintentionally consolidating their wallet at high feerates is a bug
06:36 < sipa> i guess that is a bug, though not a regression
06:36 < achow101> I think we've known about this bug for about a decade
06:37 < _aj_> murch[m]: bug/misfeature, sure
06:37 < sipa> well i think it has become more concrete - it's been known since forever that coin selection is suboptimal
06:37 < fjahr> what sipa said, yes, but the devil is in the details
06:37 < sipa> but "it's spending two orders more UTXOs than necessary at very high feerate" is still something else than "suboptimal"
06:38 < _aj_> sipa: "do your utxo sizes follow a log-normal distribution" would be my guess at a metric
06:39 < murch[m]> Yeah, personally I’d be pretty pissed if my wallet spent 25 mBTC in fees more than necessary.
06:40 < achow101> #topic Stratum v2 (Sjors[m])
06:40 < Sjors[m]> Basically I plan to take over #27854
06:40 <@gribble> https://github.com/bitcoin/bitcoin/issues/27854 | [WIP] add a stratum v2 template provider by ccdle12 · Pull Request #27854 · bitcoin/bitcoin · GitHub
06:40 < Sjors[m]> I already managed to rebase it, will make a PR shortly.
06:40 < sipa> Sjors[m]: oh cool
06:40 < Sjors[m]> And then actually try understand what it's doing and read the spec :-)
06:41 < Sjors[m]> I have a little vintage s9 to test with too.
06:41 < achow101> have you talked to the original author?
06:42 < Sjors[m]> Nobody has in the past several months unfortunately
06:43 < Sjors[m]> I did talk to the Stratum v2 folks on their discord.
06:43 < Sjors[m]> There's a newer branch by Fi3 that I'm starting from.
06:43 < sipa> Sjors[m]: i'd at least comment on the PR to announce your intention
06:43 < fjahr> apparently jonatack spoke with them: https://github.com/bitcoin/bitcoin/issues/28642#issuecomment-1765248677
06:44 < Sjors[m]> Yes, and we can even leave that PR open for a bit.
06:45 < fanquake> sounds like someone has spoken to them in the past several months then?
06:45 < fanquake> and the response was "a six-month window for refactoring, adding a lot more tests and structuring the proposed changes in a way that is easier for contributors to review sounds doable to me."
06:45 < fanquake> what's the impetus to take the PR over?
06:45 < fanquake> Or is the above no-longer true, and the author no-longer working on it?
06:45 < Sjors[m]> fanquake: Pavlenex asking me to
06:46 < achow101> fanquake: he hasn't really responded to any of the previously left review
06:47 < maflcko> I think it would be better if you offered to the author to help or take it over. Just opening an alternative and closing seems a bit rushed, without any prior communication.
06:47 < sipa> yeah, i think it'd be good to discuss the plan, whatever it is, on the currently open PR
06:48 < sipa> maybe there is a miscommunication, or unclear expectations, because from that comment linked to, it doesn't sound like the author has given up on it at all
06:48 < Sjors[m]> Miscommnication is certainly possible.
06:48 < sipa> but the lack of activity is worrying
06:48 -!- marcofleon [~marcofleo@87.125.242.19] has joined #bitcoin-core-dev
06:48 < Sjors[m]> I'll leave a link to my branch on that PR and wait to see what happens.
06:49 < achow101> any other topics to discuss?
06:49 < Sjors[m]> This is the branch people are currently testing with: https://github.com/bitcoin/bitcoin/compare/master...Fi3:bitcoin:PatchTemplates
06:50 < Sjors[m]> Last commit from original author on that one is Oct 26, which isn't ages agao.
06:50 < sipa> right
06:52 < achow101> #endmeeting
06:52 -!- kashifs [~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com] has quit [Quit: Client closed]
06:52 -!- guest-127 [~guest-127@212.129.84.94] has quit [Quit: Client closed]
06:53 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7bc8c5312bf5...c4d47d2c22fc
06:53 < bitcoin-git> bitcoin/master 66c4b58 fanquake: guix: switch from guix environment to guix shell
06:53 < bitcoin-git> bitcoin/master c4d47d2 fanquake: Merge bitcoin/bitcoin#26077: guix: switch from `guix environment` to `guix...
06:53 < bitcoin-git> [bitcoin] fanquake merged pull request #26077: guix: switch from `guix environment` to `guix shell` (master...guix_shell_over_environment) https://github.com/bitcoin/bitcoin/pull/26077
06:55 < pinheadmz> #27375 has an ACK from vasild, willcl-ark_ and maflcko any time to rereview this week? 
06:55 <@gribble> https://github.com/bitcoin/bitcoin/issues/27375 | net: support unix domain sockets for -proxy and -onion by pinheadmz · Pull Request #27375 · bitcoin/bitcoin · GitHub
07:01 < fjahr> murch[m]: would you agree generally that the coin selection algorithm will only make all users happy in all feasible scenarios if the users provide additional information: i.e. “I think this is a high fee environment now” or “consolidate a bit because I think fees will get higher soon”? I vaguely remember discussions on passing additional information to coin selection but it was years ago. Not saying that this will 
07:01 < fjahr> be easy but are there plans to go into this direction in the future?
07:02 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c4d47d2c22fc...d80318d21110
07:02 < bitcoin-git> bitcoin/master fafcee4 MarcoFalke: ci: Rename test script to 03_test_script.sh
07:02 < bitcoin-git> bitcoin/master fad82fe MarcoFalke: ci: Reduce use of bash -c
07:02 < bitcoin-git> bitcoin/master d80318d fanquake: Merge bitcoin/bitcoin#28954: ci: Reduce use of bash -c
07:02 < bitcoin-git> [bitcoin] fanquake merged pull request #28954: ci: Reduce use of bash -c (master...2311-ci-) https://github.com/bitcoin/bitcoin/pull/28954
07:04 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d80318d21110...05d3f8e82228
07:04 < bitcoin-git> bitcoin/master e67634e Sebastian Falbesoner: fuzz: BIP324: damage ciphertext/aad in full byte range
07:04 < bitcoin-git> bitcoin/master 05d3f8e fanquake: Merge bitcoin/bitcoin#28951: fuzz: BIP324: damage ciphertext/aad in full b...
07:04 < bitcoin-git> [bitcoin] fanquake merged pull request #28951: fuzz: BIP324: damage ciphertext/aad in full byte range (master...202311-fuzz-bip324-damage_in_full_byte_range) https://github.com/bitcoin/bitcoin/pull/28951
07:05 < bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/05d3f8e82228...c7f0e9738337
07:05 < bitcoin-git> bitcoin/master 2d2ef2f Hennadii Stepanov: msvc: No need to specify the default feature for `libevent` package
07:06 < bitcoin-git> bitcoin/master 1f97e51 Hennadii Stepanov: msvc: Update vcpkg manifest baseline up to "2023.08.09 Release"
07:06 < bitcoin-git> bitcoin/master 6d05c4f Hennadii Stepanov: msvc: Specify `boost-date-time` package explicitly
07:06 < bitcoin-git> [bitcoin] fanquake merged pull request #28938: msvc: Update vcpkg manifest (master...231125-vcpkg) https://github.com/bitcoin/bitcoin/pull/28938
07:07 < vasild> fjahr: indeed! I totally agree
07:08 -!- darosior [~darosior@109.205.214.46] has quit [Ping timeout: 252 seconds]
07:08 < sipa> _aj_: distribution of UTXO values is one aspect of wallet UTXO health, but just the number of UTXOs matters too (and unfortunately, the optimal number probably depends on your activity - more frequent outbound payments may mean you need more UTXOs to not tie up your entire balance in in-flight transactions e.g.)
07:09 -!- theStack [~theStack@95.179.145.232] has quit [Quit: theStack]
07:09 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-dev
07:10 < sipa> fjahr: i'm not sure that making users responsible for guessing long-term feerate is a very relevant change (no objection to allowing that as an expert option, but i can't imagine many users to bother or have a good idea about it)
07:10 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7f0e9738337...cdb772313c03
07:10 < bitcoin-git> bitcoin/master a4980da fanquake: guix: remove input labels
07:10 < bitcoin-git> bitcoin/master cdb7723 fanquake: Merge bitcoin/bitcoin#28965: guix: remove input labels
07:10 < bitcoin-git> [bitcoin] fanquake merged pull request #28965: guix: remove input labels (master...guix_drop_input_label) https://github.com/bitcoin/bitcoin/pull/28965
07:11 -!- darosior [~darosior@109.205.214.46] has joined #bitcoin-core-dev
07:11 < vasild> sipa: I think this is all about "guessing long-term feerate" and somebody has to do it, either the software or the user, or both
07:11 < _aj_> sipa: i'm not sure that's very meaningful: if your outgoing payments are all valued at 0.42 BTC (salary payments?), but your incoming coins are all much smaller (0.003 BTC textbook sales?), then every tx is going to spend 140 inputs, but that's not a bug, it's just how things are.
07:11 < fjahr> sipa: yes, but forcing the user to make a decision would lead to less surprises. Just asking the user to decide if it's a good time to consolidate or not would probably have solved the issue with the 500 inputs. 
07:12 < sipa> fjahr: fair enough; i think something similar can be achieved by just offering an explicit consolidation option too
07:13 < vasild> a slider with "cheap" on one end and "consolidate" at the other end
07:13 < sipa> fjahr: i don't think the 500 inputs issue is due to not knowing long-term feerate
07:13 < fjahr> sipa: yeah, that would be the most simple option, but maybe there are more user friendly ideas
07:13 < sipa> we *have* a long-term feerate, it's not particularly sophisticated, but it does something
07:14 < bitcoin-git> [bitcoin] fanquake closed pull request #28846: depends: fix libmultiprocess build on aarch64 (master...fixup_multiprocess_arm64) https://github.com/bitcoin/bitcoin/pull/28846
07:14 < sipa> the problem is that we have no coin selection algorithm that's really aimed at minimizing the input set; if we had one, it *would* win
07:14 < fjahr> sipa: The way i imagine it, the wallet would have restricted the number of inputs if the user had said, now is not a great time to consolidate
07:15 < sipa> fjahr: we run multiple coin selection algorithms, and then pick the best one we found, according to the waste metric
07:16 < sipa> an input with 500 inputs, today in a high-fee environment, *would be* considered terrible waste; it gets selected anyway because it's the only solution we found at all
07:16 < sipa> adding a coin selection algorithm that minimizes the number of inputs would be considered much better
07:17 < sipa> and there is a PR that does that, but at least my concern is that it - at much lower feerates - would still be picked
07:20 < fjahr> sipa: yes, that was discussed earlier, i am aware of the different coin selection algos on a high level. I guess they would still need to be composed in a better way and letting the user indicate if they think it's a good time to consolidate could help with that.
07:21 < fjahr> *when that new algo is added
07:21 < bitcoin-git> [bitcoin] fanquake opened pull request #28973: ci: remove `libz-dev` from macOS build deps (master...macos_drop_libz_dev) https://github.com/bitcoin/bitcoin/pull/28973
07:21 -!- baakeydow [~baake@2001:41d0:203:b12c::] has joined #bitcoin-core-dev
07:21 < sipa> fjahr: my point is that the current problem is not due to not knowing long-term feerate
07:22 < sipa> that's an independent improvement
07:23 < fjahr> sipa: ack
07:32 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
07:35 -!- marcofleon [~marcofleo@87.125.242.19] has quit [Quit: Connection closed]
07:42 -!- zato [~zato@user/zato] has quit [Read error: Connection reset by peer]
07:45 -!- realies [~realies@user/realies] has joined #bitcoin-core-dev
07:46 -!- zato [~zato@user/zato] has joined #bitcoin-core-dev
07:48 < instagibbs> sdaftuar does it make sense to use bypass_limits to allow ephemeral anchor-having tx in on its own? Right now I think all ephemeral anchor txns are simply dropped because of one-by-one submission, which will fail in PreCheck. Then we can(or not) check if the anchor has been spent for filtering(or not).
07:49 < sdaftuar> i was just thinking about that issue myself this morning
07:50 < sdaftuar> i think that seems safe, but it's sort of a shame to add an extra condition to the filter that applies to all transactions, when we know the scope of what could be affected in this way is really limited to what was just re-added from a block.
07:51 < sdaftuar> probably the performance concern is negligible compared to what we're already doing though.
07:53 < instagibbs> I think we want the ephemeral txns to re-enter the mempool (hence bypass_limits), question is more should we filter, I think. Are there situations where a spend of the output wouldn't make it back in? I presume there are cases
07:53 < instagibbs> I'm less familiar with this section of the code
07:53 < sdaftuar> yes i think so
07:53 < sdaftuar> in a reorg, it's entirely possible that a spend of the EA output could be non-standard to your node
07:54 < instagibbs> ah yeah, miner mines something non-standard
07:54 < instagibbs> f.e.
07:54 < sdaftuar> yep
07:54 < instagibbs> let's say we're in a priority txn world but your node isn't, could definitely happen
07:54 < instagibbs> hmm
07:54 < sdaftuar> although i think glozow made the point somewhere that we'd evict 0-fee transactions, which would also fix that for you\
07:55 < instagibbs> Oh.... yeah
07:55 < instagibbs> well, unless a standard spend of *other* outputs are entered
07:55 < sdaftuar> good point!
07:55 < instagibbs> so you'd still have the dust
07:55 < sdaftuar> right, probably we should filter
07:56 < instagibbs> if we get this wrong, probably still mostly ok in that these anchors could be cleaned up by a nice miner 🙏
07:56 < instagibbs> but I agree, err on cleanliness
07:57 < _aj_> there's dust in the utxo set due to spending to 0 as a p2pkh; random dust created by reorgs doesn't seem like that big a problem?
08:03 < instagibbs> I could go either way. I don't want the work to get derailed arguing that some sweepable dust in some rare cases is ok, but if there's not a lot of pushback, I'm fine.
08:04 < _aj_> yeah, just agreeing that it's not a disaster if things go wrong
08:08 -!- instagibbs_ [uid142535@id-142535.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
08:11 -!- realies [~realies@user/realies] has quit [Quit: ~]
08:12 < bitcoin-git> [bitcoin] ryanofsky pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/cdb772313c03...ffb021612b8f
08:12 < bitcoin-git> bitcoin/master fa7eb4f MarcoFalke: fuzz: Drop unused version from fuzz input format
08:12 < bitcoin-git> bitcoin/master fae00fe MarcoFalke: Remove unused CDataStream
08:12 < bitcoin-git> bitcoin/master fa0ae22 MarcoFalke: Remove unused SER_NETWORK, SER_DISK
08:12 < bitcoin-git> [bitcoin] ryanofsky merged pull request #28451: refactor: Remove unused SER_DISK, SER_NETWORK, CDataStream (master...2309-no-ser-hash-) https://github.com/bitcoin/bitcoin/pull/28451
08:20 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has joined #bitcoin-core-dev
08:36 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
08:36 -!- dviola [~diego@user/dviola] has quit [Quit: WeeChat 4.1.1]
08:49 -!- Guest56 [~Guest75@103.87.236.96] has joined #bitcoin-core-dev
08:52 -!- Guest56 [~Guest75@103.87.236.96] has quit [Client Quit]
08:52 -!- Guest18 [~Guest75@103.87.236.96] has joined #bitcoin-core-dev
08:55 < bitcoin-git> [bitcoin] BrandonOdiwuor opened pull request #28974: doc: explain what the wallet password does (master...wallet_passphrase) https://github.com/bitcoin/bitcoin/pull/28974
08:57 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
09:10 -!- Guest18 [~Guest75@103.87.236.96] has quit [Ping timeout: 250 seconds]
09:55 < fanquake> We've merged a few Guix related changes into master
09:55 < fanquake> As far as we can tell, this shouldn't break anything for anyone (tested with Guix 1.2.0 from ~3 years ago, and builds worked ok)
09:56 < fanquake> But if anyone who regular builds, wants to build master / happens to find any issues, please open an issue
10:09 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:18 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has quit [Remote host closed the connection]
10:19 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has joined #bitcoin-core-dev
10:21 -!- zato [~zato@user/zato] has quit [Quit: Om mani padme hum]
10:24 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has quit [Ping timeout: 256 seconds]
10:40 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
10:43 < sdaftuar> instagibbs: this is an implementation detail, but the way the mempool filter after a reorg works is that we evaluate each transaction in the mempool in isolation, and potentially mark it for removal.  it's possible that an EA transaction would pass the filter (because it has a child spending its EA output) but the child gets marked for removal.
10:43 < sdaftuar> this would result in the EA transaction sticking around without a spend. to correctly filter those transactions, you have to look at them after the filtering has happened
10:44 < instagibbs> mmm right
10:44 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 256 seconds]
10:44 < sdaftuar> hmm, i guess this is a more general issue than just reorgs -- whenever a tx is removed from the mempool, you have to consider whether an EA output is now unspent?
10:45 < sdaftuar> that seems somewhat tedious
10:46 < instagibbs> I don't think in normal operation it can happen. A spend being added is checked that it's spending all parent anchors(the one)
10:47 < sdaftuar> i think it can. suppose P is a parent transaction with an EA output, and a regular output.  It gets added to the mempool with an EA spend. later, a higher feerate spend of the non-EA output is added, and eventually the EA spend transaction (which has lower descendant feerate now, or is in a lower chunk in the cluster mempool world) gets evicted
10:48 < instagibbs> > later, a higher feerate spend of the non-EA output is added
10:48 < instagibbs> that's two descendants of parent?
10:48 < sdaftuar> so that's parent P, child C1 (EA spend) and child C2 (non-EA spend)
10:48 < sdaftuar> P+C1 is added to the mempool initially; later C2 is added also spending another output of P.
10:49 < sdaftuar> C1 could be removed from the mempool due to eviction or RBF, for that matter
10:50 < instagibbs> you can't have two descendants of parent
10:50 < instagibbs> it's v3
10:50 < sdaftuar> ahh, ok
10:50 < instagibbs> and any child MUST\ spend the anchor
10:50 < instagibbs> """sibling eviction"""
10:51 < instagibbs> in a non-v3 world the exact requirement would be "only one direct child of ephemeral anchor tx", otherwise you'd end up as you say
10:51 < murch[m]> fjahr: You can configure the long term feerate estimate, which would change the behavior in that manner
10:52 < sdaftuar> so this works because (a) it must be v3 (so only one child), (b) and EA transactions must have 0 fee (so that if its child ever disappears, it gets evicted from the mempool).
10:52 < sdaftuar> and then it's just in the reorg case where that last property might not hold
10:52 < instagibbs> 👍
10:52 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has joined #bitcoin-core-dev
10:52 < instagibbs> right now it gets evicted in reorg, but even in the case where it has a spend
10:52 < instagibbs> (I need a test for this, heh)
10:53 < sdaftuar> right, and with the bypass_limits extension we can fix that i guess
10:54 < murch[m]> and as sipa said, yes the issue is that we can’t predict whether the feerate is lower than the future or not
10:55 < murch[m]> Yet, even though we currently treat 75 s/vB as a high feerate, the input set selection doesn’t reflect that information
10:59 < instagibbs> sdaftuar hmmm think I can actually delete code. Thought I was missing test coverage from your line of questioning, realized I literally can't hit the check, assuming V3 is working properly 
10:59 < instagibbs> nice
11:00 < instagibbs> well, except reorgs 😬
11:01 -!- salvatoshi [~salvatosh@194.65.48.125] has quit [Ping timeout: 260 seconds]
11:13 -!- salvatoshi [~salvatosh@2001:818:e733:2700:a0eb:63f:e256:da39] has joined #bitcoin-core-dev
11:15 -!- boris- [~boris@201.189.64.198] has joined #bitcoin-core-dev
11:17 -!- pablomartin [~pablomart@103.50.33.51] has joined #bitcoin-core-dev
11:28 -!- benwestgate [~BenWestga@2603-8080-74f0-e960-8b9f-e9eb-cc22-8be1.res6.spectrum.com] has quit [Quit: Leaving.]
11:29 < bitcoin-git> [bitcoin] achow101 pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/ffb021612b8f...498994b6f55d
11:29 < bitcoin-git> bitcoin/master be4ff30 Hennadii Stepanov: Move global `scriptcheckqueue` into `ChainstateManager` class
11:29 < bitcoin-git> bitcoin/master d03eaac Hennadii Stepanov: Make `CCheckQueue` destructor stop worker threads
11:29 < bitcoin-git> bitcoin/master 9cf89f7 Hennadii Stepanov: refactor: Make `CCheckQueue` constructor start worker threads
11:29 -!- martinus [~martinus@2001:4bc9:802:1325:ce4:a0d6:761e:5] has joined #bitcoin-core-dev
11:29 < bitcoin-git> [bitcoin] achow101 merged pull request #26762: bugfix: Make `CCheckQueue` RAII-styled (attempt 2) (master...221228-queue) https://github.com/bitcoin/bitcoin/pull/26762
11:30 -!- kashifs [~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com] has joined #bitcoin-core-dev
11:30 -!- kashifs [~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com] has quit [Client Quit]
11:46 -!- benwestgate [~BenWestga@035-146-116-233.res.spectrum.com] has joined #bitcoin-core-dev
11:53 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has quit [Remote host closed the connection]
11:56 -!- Chris_Stewart_5 [~Chris_Ste@146.70.211.124] has quit [Ping timeout: 260 seconds]
11:58 -!- Chris_Stewart_5 [~Chris_Ste@87.249.134.39] has joined #bitcoin-core-dev
12:07 < jonatack> Sjors[m]: cool, would be good to see progress on stratum v2. I sent a message linking to today's discussion.
12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:11 < jonatack> murch[m]: thank you for the reminder about the coingrinder pull
12:11 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has joined #bitcoin-core-dev
12:14 < jonatack> With respect to https://delvingbitcoin.org, is there an advantage to having discussions there, rather than in a github issue? afaik the github metadata is backed up regurlarly -- it is good that the discussions take place publicly though :+1:
12:22 < _aj_> i find discussions in github issues/prs/gists get lost pretty easily; opening up topics/etc on a forum vs filing random issues seems less annoying; having admin control over adding plugins and moderation may be better than relying on github/etc.
12:24 < _aj_> jonatack: also, #28318...
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/28318 | logging: Simplify API for level based logging by ajtowns · Pull Request #28318 · bitcoin/bitcoin · GitHub
12:26 -!- pablomartin [~pablomart@103.50.33.51] has quit [Ping timeout: 255 seconds]
12:27 < jonatack> _aj_: yes, that pull is on my list, i've been prioritising the p2p bugfixes but will get there, ty for the reminder
12:28 < jonatack> _aj_: i like having the discussions in one place and haven't signed up yet for delving (it is better than the ML though)
12:29 < jonatack> i don't have the habit of looking in delving yet but have opened it a few times
12:29 -!- pablomartin [~pablomart@193.160.246.221] has joined #bitcoin-core-dev
12:35 < sipa> fwiw, delving is also archived
12:42 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has joined #bitcoin-core-dev
12:53 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
12:53 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-dev
12:53 < BlueMatt[m]> apparently bitcoin core doesn't properly decode 0-input transactions which are encoded with the segwit marker byte when passed to decoderawtransaction? https://github.com/rust-bitcoin/rust-bitcoin/issues/2238
12:53 < _aj_> they can be ambiguous, yeah
12:53 < BlueMatt[m]> rust-bitcoin deliberately encodes 0-input transactions with the marker bytes because it resolves the ambiguity
12:54 < BlueMatt[m]> if you have the marker bytes its not ambiguous
12:54 < jonatack> Sjors[m]: discussed with moneyball____ and he said they haven't been getting updated, "So Sjors bless his heart is helping"
12:54 < BlueMatt[m]> or, at least, if you know they're there its not ambiguous, but maybe still is if you're not sure? i long ago swapped this all out of my head :(
12:55 < _aj_> there's an "iswitness" flag for decoderawtransaction that you can use if you know they've been encoded with witness flag?
12:55 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has joined #bitcoin-core-dev
12:56 < sipa> BlueMatt[m]: BIP144 says you cannot use the extended encoding if there are no witnesses
12:56 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has quit [Client Quit]
12:56 < BlueMatt[m]> yes, but BIP144 is about consensus, and these are not consensus :p
12:56 < BlueMatt[m]> _aj_: ah, that's helpful, thanks
12:57 -!- Guest77 [~Guest41@2600:6c60:57f0:b20:a14c:441b:6c51:65fa] has joined #bitcoin-core-dev
12:58 < jonatack> Sjors[m]: so if you don't see a reply soonish to your comment today at https://github.com/bitcoin/bitcoin/pull/27854#issuecomment-1833934826 it sounds good to move forward
12:58 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has joined #bitcoin-core-dev
12:58 < sipa> BlueMatt[m]: no, BIP144 is P2P protocol; though fair enough, RPC isn't P2P either
12:59 < Sjors[m]> jonatack: thanks, I'll take a look tomorrow or Monday
12:59 -!- Guest77 [~Guest41@2600:6c60:57f0:b20:a14c:441b:6c51:65fa] has quit [Client Quit]
12:59 < BlueMatt[m]> sipa: in general, somehow I had recalled bitcoin core's "heuristic" here to be "try both, and if only one manages to read the full buffer successfully use that"
12:59 < BlueMatt[m]> which would imply that setting the marker bytes is more likely to resolve correctly
12:59 < BlueMatt[m]> but i guess thats not what it does?
12:59 < sipa> BlueMatt[m]: yes, in case of ambiguity; but it will never permit marker bytes in case there is no witness, because that's just not valid 
13:00 < _aj_> there's other heuristics like is the output amount sensible iirc
13:01 < BlueMatt[m]> sipa: I mean in general it seems like modern software really should be setting the marker bytes, exactly to avoid the ambiguity.
13:01 < sipa> BlueMatt[m]: nacl
13:01 < sipa> nack
13:01 < BlueMatt[m]> _aj_: ah, fair, but in any case that seems to imply it should work fine with zero-input-marker-bytes
13:01 < BlueMatt[m]> sipa: can you elaborate :)
13:01 < _aj_> nah, sipa's right; CTransaction deserialize just fails in that case
13:02 < BlueMatt[m]> right, okay, so ignoring for a moment what it does, what should it do :)
13:02 < sipa> i think it does the right thing
13:02 < BlueMatt[m]> yes, so I've provided my justification, please provide yours, then lets talk about the relative tradeoffs :)
13:03 < bitcoin-git> [bitcoin] achow101 opened pull request #28976: Migrate blank (master...migrate-blank) https://github.com/bitcoin/bitcoin/pull/28976
13:03 < sipa> it accepts all valid encodings; for valid transactions that's unambiguous; if you have invalid things (like ones without inputs...) there format is ambiguous, so it guesses
13:03 < _aj_> could add a special case for !tx.HasWitness() && tx.vin.size() == 0
13:03 < sipa> i strongly disagree with having multiple encodings for the same data
13:04 -!- ___nick___ [~quassel@host81-129-235-34.range81-129.btcentralplus.com] has quit [Ping timeout: 240 seconds]
13:04 < _aj_> better than than different data having the same encoding?
13:04 < BlueMatt[m]> so if you're writing a bitcoin parsing library, and you have to parse transactions with no context, and sometimes without a known length, istm you should almost certainly rely on the segwit marker for 0-input transactions
13:04 < sipa> i mean... why do you have transactions with 0 inputs anyway?
13:04 < BlueMatt[m]> cause people havent yet adopted psbt universally, sadly
13:06 < BlueMatt[m]> I mean if we try to decode all "0 inputs" as using the segwit marker byte from day one, I'd argue at this point we should be removing the legacy encoding logic for 0 inputs entirely today :)
13:06 < _aj_> https://github.com/bitcoin/bitcoin/pull/17775#issuecomment-580584699 hah
13:06 < BlueMatt[m]> so long-term we'd end up with one encoding
13:07 < BlueMatt[m]> ah! its instagibbs' fault
13:07 < sipa> i guess we could say the correct serialization for transactions with 0 inputs but more than 0 outputs is using the extended format too there?
13:07 < BlueMatt[m]> that's what rust-bitcoin does
13:07 < _aj_> or we could say the correct format is psbt :)
13:07 < sipa> BlueMatt[m]: i don't care that much about 0-input transactions, but i'm vehemently against permitting extended encoding for *valid* transactions without witness
13:07 < BlueMatt[m]> cause we didnt want to deal with the ambiguity (which usually requires retrying deserialization to resolve, which is annoying)
13:08 < BlueMatt[m]> sipa: fair enough, yes, that makes sense
13:08 < BlueMatt[m]> _aj_: ha, well if you read the rust-bitcoin issue that was also the response lol
13:09 < sipa> let me see how much breaks if i change that
13:10 -!- phantomcircuit_ [~phantomci@2604:a880:1:20::f2:c001] has quit [Quit: ZNC - https://znc.in]
13:12 < BlueMatt[m]> yea, indeed, rust-bitcoin will reject transactions serialized with > 0 inputs with no witnesses
13:12 < BlueMatt[m]> https://github.com/rust-bitcoin/rust-bitcoin/blob/master/bitcoin/src/blockdata/transaction.rs#L1102
13:13 < achow101> BlueMatt[m]: have you heard about our lord and savior psbt?
13:13 < sipa> achow101: he has, but apparently some of his users haven't seen The Light yet.
13:14 < BlueMatt[m]> achow101: you can join the "just use psbt" bashing party at https://github.com/rust-bitcoin/rust-bitcoin/issues/2238 if you want :)
13:22 -!- phantomcircuit [~phantomci@2604:a880:1:20::f2:c001] has joined #bitcoin-core-dev
13:26 < bitcoin-git> [bitcoin] murchandamus opened pull request #28977: Add Gutter Guard Selector (master...2023-11-gutter-guard-selector) https://github.com/bitcoin/bitcoin/pull/28977
13:27 < bitcoin-git> [bitcoin] ryanofsky opened pull request #28978: doc: Add multiprocess design doc (master...pr/ipcdoc) https://github.com/bitcoin/bitcoin/pull/28978
13:31 -!- Guyver2_ [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
13:39 < murch[m]> Re today’s meeting. Here’s a draft of a stupid simple coin selection algorithm that curbs unnecessary fee spending at high feerates while still usually being slightly consolidatory. Basically, a bound on the worst case: https://github.com/bitcoin/bitcoin/pull/28977
13:40 < instagibbs> BlueMatt[m] I remember literally none of this 
13:41 < murch[m]> cc: fjahr, Sjors, vasild, instagibbs
13:41 < instagibbs> I need a gutter guard, how did you know
13:42 -!- martinus [~martinus@2001:4bc9:802:1325:ce4:a0d6:761e:5] has quit [Quit: Konversation terminated!]
13:43 < murch[m]> I’ll add some simulations by next week
13:46 < BlueMatt[m]> <instagibbs> "Matt Corallo I remember literall..." <- convenient excuse
13:49 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
13:54 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 276 seconds]
14:05 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has quit [Remote host closed the connection]
14:26 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.1.1]
14:30 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has joined #bitcoin-core-dev
14:35 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e] has quit [Ping timeout: 268 seconds]
14:47 -!- pablomartin [~pablomart@193.160.246.221] has quit [Ping timeout: 245 seconds]
14:53 -!- pablomartin [~pablomart@193.160.246.224] has joined #bitcoin-core-dev
14:55 -!- benwestgate [~BenWestga@035-146-116-233.res.spectrum.com] has quit [Quit: Leaving.]
14:56 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
14:59 < bitcoin-git> [bitcoin] ishaanam opened pull request #28979: wallet, rpc: document and update `sendall` behavior around unconfirmed inputs (master...sendall_ancestor_aware_funding) https://github.com/bitcoin/bitcoin/pull/28979
14:59 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 252 seconds]
15:07 -!- raini_ok [~raini_ok@user/raini-ok/x-7871157] has joined #bitcoin-core-dev
15:13 -!- pablomartin [~pablomart@193.160.246.224] has quit [Ping timeout: 256 seconds]
15:41 -!- Guest16 [~Guest16@108-77-84-183.lightspeed.rlghnc.sbcglobal.net] has joined #bitcoin-core-dev
15:43 -!- Guest16 [~Guest16@108-77-84-183.lightspeed.rlghnc.sbcglobal.net] has quit [Client Quit]
16:00 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Remote host closed the connection]
16:00 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
16:43 -!- raini_ok [~raini_ok@user/raini-ok/x-7871157] has quit [Ping timeout: 276 seconds]
16:47 < bitcoin-git> [bitcoin] furszy opened pull request #28980: rpc: encryptwallet help, mention HD seed rotation and backup requirement (master...2023_rpc_wallet_encryptwallet) https://github.com/bitcoin/bitcoin/pull/28980
17:42 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
17:47 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
17:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
18:04 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
18:05 < bitcoin-git> [bitcoin] hebasto opened pull request #28981: POC: Replace Boost.Process with cpp-subprocess (master...231130-replace-bp) https://github.com/bitcoin/bitcoin/pull/28981
18:08 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
18:33 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b039:cf67:d233:d927] has joined #bitcoin-core-dev
18:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
18:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
19:31 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:35 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 276 seconds]
19:42 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b039:cf67:d233:d927] has quit [Remote host closed the connection]
19:48 -!- Guest76 [~Guest76@125.167.59.23] has joined #bitcoin-core-dev
19:56 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b039:cf67:d233:d927] has joined #bitcoin-core-dev
19:56 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b039:cf67:d233:d927] has quit [Remote host closed the connection]
20:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
20:05 -!- Guest76 [~Guest76@125.167.59.23] has quit [Quit: Client closed]
20:22 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
20:36 -!- boris- [~boris@201.189.64.198] has quit [Read error: Connection reset by peer]
20:38 -!- boris [~boris@user/boris] has joined #bitcoin-core-dev
20:42 -!- mxz [~mxz@user/mxz] has quit [Quit: cya]
20:43 -!- mxz [~mxz@user/mxz] has joined #bitcoin-core-dev
20:44 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
20:48 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:20 -!- Guest30 [~Guest30@216-17-75-5.fttp.usinternet.com] has joined #bitcoin-core-dev
21:22 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:28 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
21:30 -!- Guest30 [~Guest30@216-17-75-5.fttp.usinternet.com] has quit [Ping timeout: 250 seconds]
21:56 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:01 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
22:05 -!- benwestgate [~BenWestga@035-146-116-233.res.spectrum.com] has joined #bitcoin-core-dev
22:18 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
22:47 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
23:10 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
23:11 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
23:16 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
23:20 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 252 seconds]
23:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:26 -!- benwestgate [~BenWestga@035-146-116-233.res.spectrum.com] has quit [Quit: Leaving.]
23:31 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
23:36 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has quit [Ping timeout: 268 seconds]
23:39 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has joined #bitcoin-core-dev
--- Log closed Fri Dec 01 00:00:41 2023