12023-11-30T00:44:59 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
22023-11-30T00:49:47 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
32023-11-30T00:54:17 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:440d:a69b:595b:1578> has joined #bitcoin-core-dev
42023-11-30T00:57:05 *** kevkevin_ <kevkevin_!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has joined #bitcoin-core-dev
52023-11-30T00:59:24 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:440d:a69b:595b:1578> has quit IRC (Ping timeout: 268 seconds)
62023-11-30T01:17:36 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
72023-11-30T01:24:26 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
82023-11-30T01:30:13 *** kevkevin_ <kevkevin_!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has quit IRC (Remote host closed the connection)
92023-11-30T01:51:04 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has joined #bitcoin-core-dev
102023-11-30T02:37:42 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has quit IRC (Remote host closed the connection)
112023-11-30T02:40:09 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has joined #bitcoin-core-dev
122023-11-30T02:43:21 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has quit IRC (Remote host closed the connection)
132023-11-30T02:43:52 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has joined #bitcoin-core-dev
142023-11-30T02:52:06 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
152023-11-30T02:56:50 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
162023-11-30T02:58:18 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has quit IRC (Remote host closed the connection)
172023-11-30T03:20:05 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
182023-11-30T03:24:51 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 252 seconds)
192023-11-30T03:44:16 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
202023-11-30T03:48:08 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
212023-11-30T03:53:18 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 268 seconds)
222023-11-30T03:53:52 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
232023-11-30T03:58:47 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
242023-11-30T04:13:09 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has joined #bitcoin-core-dev
252023-11-30T04:21:11 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has quit IRC (Remote host closed the connection)
262023-11-30T04:22:05 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has joined #bitcoin-core-dev
272023-11-30T04:22:09 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:ac4f:bbaa:f4f4:1e92> has quit IRC (Remote host closed the connection)
282023-11-30T04:34:50 *** pablomartin <pablomartin!~pablomart@103.50.33.63> has quit IRC (Ping timeout: 260 seconds)
292023-11-30T04:49:28 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
302023-11-30T04:54:13 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 255 seconds)
312023-11-30T05:01:02 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
322023-11-30T05:01:37 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
332023-11-30T05:17:11 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
342023-11-30T05:22:26 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
352023-11-30T05:36:42 *** BUSY <BUSY!~BUSY@user/busy> has quit IRC (Quit: Leaving)
362023-11-30T05:45:47 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
372023-11-30T05:50:03 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 252 seconds)
382023-11-30T06:35:08 *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@37.19.200.155> has quit IRC (Ping timeout: 255 seconds)
392023-11-30T06:36:56 *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@146.70.211.124> has joined #bitcoin-core-dev
402023-11-30T06:45:10 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
412023-11-30T06:47:44 *** benwestgate <benwestgate!~BenWestga@2603-8080-74f0-e960-8b9f-e9eb-cc22-8be1.res6.spectrum.com> has joined #bitcoin-core-dev
422023-11-30T06:50:23 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
432023-11-30T06:50:56 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
442023-11-30T06:55:38 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 256 seconds)
452023-11-30T06:56:19 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
462023-11-30T07:01:43 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
472023-11-30T07:16:02 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
482023-11-30T07:18:31 *** javi404 <javi404!~quassel@2601:582:0:2c41:91ca:6895:2072:3474> has quit IRC (Ping timeout: 260 seconds)
492023-11-30T07:19:38 *** javi404 <javi404!~quassel@2601:582:0:2c41:91ca:6895:2072:3474> has joined #bitcoin-core-dev
502023-11-30T07:26:23 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
512023-11-30T07:40:17 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
522023-11-30T07:50:25 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 268 seconds)
532023-11-30T07:55:42 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
542023-11-30T07:56:31 *** zato <zato!~zato@user/zato> has joined #bitcoin-core-dev
552023-11-30T08:14:06 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
562023-11-30T08:24:01 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 268 seconds)
572023-11-30T08:45:41 *** salvatoshi <salvatoshi!~salvatosh@194.65.48.125> has joined #bitcoin-core-dev
582023-11-30T08:48:03 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
592023-11-30T08:52:47 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
602023-11-30T09:10:09 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
612023-11-30T09:15:12 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 252 seconds)
622023-11-30T09:31:37 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
632023-11-30T09:32:43 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev
642023-11-30T09:46:57 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
652023-11-30T09:52:11 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
662023-11-30T09:52:44 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
672023-11-30T09:57:00 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 252 seconds)
682023-11-30T10:19:55 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
692023-11-30T10:24:53 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 268 seconds)
702023-11-30T10:26:59 *** dviola <dviola!~diego@user/dviola> has joined #bitcoin-core-dev
712023-11-30T10:52:06 *** Guest47 <Guest47!~Guest47@2603-9001-1700-3915-30c0-2bf5-446f-7068.inf6.spectrum.com> has joined #bitcoin-core-dev
722023-11-30T10:53:46 *** Guyver2_ <Guyver2_!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
732023-11-30T10:56:07 *** Guest47 <Guest47!~Guest47@2603-9001-1700-3915-30c0-2bf5-446f-7068.inf6.spectrum.com> has quit IRC (Client Quit)
742023-11-30T11:01:05 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
752023-11-30T11:01:49 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
762023-11-30T11:23:50 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Remote host closed the connection)
772023-11-30T11:24:01 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
782023-11-30T11:24:08 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
792023-11-30T11:28:51 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 256 seconds)
802023-11-30T11:36:36 *** boris- <boris-!~boris@201.189.64.198> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
812023-11-30T11:57:17 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
822023-11-30T12:02:45 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
832023-11-30T12:07:21 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 252 seconds)
842023-11-30T12:08:18 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
852023-11-30T12:13:04 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 255 seconds)
862023-11-30T12:16:07 *** vasild <vasild!~vd@user/vasild> has quit IRC (Ping timeout: 240 seconds)
872023-11-30T12:18:12 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
882023-11-30T12:47:39 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
892023-11-30T12:52:47 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
902023-11-30T12:53:20 *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
912023-11-30T13:03:06 *** darosior6 <darosior6!~darosior@109.205.214.46> has joined #bitcoin-core-dev
922023-11-30T13:03:39 *** darosior <darosior!~darosior@109.205.214.46> has quit IRC (Read error: Connection reset by peer)
932023-11-30T13:03:39 *** darosior6 is now known as darosior
942023-11-30T13:33:30 <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?)
952023-11-30T13:37:12 *** kashifs <kashifs!~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com> has joined #bitcoin-core-dev
962023-11-30T13:39:23 <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
972023-11-30T13:54:06 <Sjors[m]> #proposedmeetingtopic: Stratum v2
982023-11-30T13:54:29 <Sjors[m]> #proposedmeetingtopic Stratum v2
992023-11-30T13:56:30 *** guest-127 <guest-127!~guest-127@212.129.84.94> has joined #bitcoin-core-dev
1002023-11-30T13:59:56 *** instagibbs_ <instagibbs_!uid142535@id-142535.tinside.irccloud.com> has joined #bitcoin-core-dev
1012023-11-30T14:00:09 <achow101> #startmeeting
1022023-11-30T14:00:16 <glozow> hi
1032023-11-30T14:00:18 <RubenSomsen> hi
1042023-11-30T14:00:20 <hebasto> hi
1052023-11-30T14:00:20 <murch[m]> Hi
1062023-11-30T14:00:23 <fjahr> hi
1072023-11-30T14:00:24 <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
1082023-11-30T14:00:27 <Sjors[m]> hi
1092023-11-30T14:00:29 <brunoerg> hi
1102023-11-30T14:00:33 <darosior> hi
1112023-11-30T14:00:34 <furszy> hi
1122023-11-30T14:00:36 <vasild> hi
1132023-11-30T14:00:52 <gleb> hi
1142023-11-30T14:00:56 <achow101> There are 2 pre-proposed meeting topics, any last minute ones to add to the list?
1152023-11-30T14:01:04 <kanzure> hi
1162023-11-30T14:01:14 <RubenSomsen> I'll do another silent payments update
1172023-11-30T14:01:41 <achow101> #topic package relay updates (glozow)
1182023-11-30T14:01:43 <sipa> hi
1192023-11-30T14:01:49 <glozow> 2 PRs are open for review: #28848 and #28948.
1202023-11-30T14:01:50 <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.
1212023-11-30T14:01:52 <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
1222023-11-30T14:01:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow · Pull Request #28948 · bitcoin/bitcoin · GitHub
1232023-11-30T14:01:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow · Pull Request #28948 · bitcoin/bitcoin · GitHub
1242023-11-30T14:01:57 <gribble> https://github.com/bitcoin/bitcoin/issues/25038 | policy: nVersion=3 and Package RBF by glozow · Pull Request #25038 · bitcoin/bitcoin · GitHub
1252023-11-30T14:01:59 <gribble> https://github.com/bitcoin/bitcoin/issues/26403 | policy: Ephemeral anchors by instagibbs · Pull Request #26403 · bitcoin/bitcoin · GitHub
1262023-11-30T14:02:00 <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
1272023-11-30T14:02:04 <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
1282023-11-30T14:02:54 <theStack> hi
1292023-11-30T14:03:38 <_aj_> hi
1302023-11-30T14:03:43 <glozow> The very exciting thing is weâll have 1p1c package relay at the end of this. And then cluster mempool!
1312023-11-30T14:03:52 <b10c> hi
1322023-11-30T14:04:02 <achow101> cool
1332023-11-30T14:04:49 <achow101> #topic silent payments updates (RubenSomsen)
1342023-11-30T14:05:02 <RubenSomsen> Still actively taking review on BIP352, responding to feedback, and wanting review on #25273.
1352023-11-30T14:05:04 <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
1362023-11-30T14:05:21 <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
1372023-11-30T14:05:31 <RubenSomsen> Could use more eyes on that
1382023-11-30T14:05:55 <sipa> fwiw, we've been having some of our cluster mempool discussions on delving: https://delvingbitcoin.org/c/implementation/wg-cluster-mempool/9
1392023-11-30T14:06:02 <maxedw> hi
1402023-11-30T14:06:27 <murch[m]> Nice to see the discussion accessible in public!
1412023-11-30T14:07:19 <achow101> #topic multiprocess updates (ryanofsky)
1422023-11-30T14:08:27 *** Murch <Murch!~Murch@user/murch> has joined #bitcoin-core-dev
1432023-11-30T14:09:11 <achow101> looks like the tracking issue was updated and several new PRs have been opened
1442023-11-30T14:09:44 <achow101> #28921 seems to be next
1452023-11-30T14:09:46 <gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky · Pull Request #28921 · bitcoin/bitcoin · GitHub
1462023-11-30T14:09:52 <ryanofsky> Hi, yes there are a few new prs opened
1472023-11-30T14:10:27 <ryanofsky> Currently working on a design doc which I want to post in a new PR this week
1482023-11-30T14:10:57 <ryanofsky> Tracking issue is https://github.com/bitcoin/bitcoin/issues/28722 if anyone is looking what to review
1492023-11-30T14:11:57 <achow101> #topic Ad-hoc high priority for review
1502023-11-30T14:12:03 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
1512023-11-30T14:12:48 <gleb> can you add #28765?
1522023-11-30T14:12:51 <gribble> https://github.com/bitcoin/bitcoin/issues/28765 | p2p: Fill reconciliation sets (Erlay) by naumenkogs · Pull Request #28765 · bitcoin/bitcoin · GitHub
1532023-11-30T14:13:25 <achow101> gleb: added
1542023-11-30T14:13:30 <gleb> thanks
1552023-11-30T14:13:59 <_aj_> #27432 has concept acks, could be dropped from there, presumably?
1562023-11-30T14:14:01 <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
1572023-11-30T14:14:01 <maflcko> Can I have #28924 ? (It is a blocker for a bugfix)
1582023-11-30T14:14:03 <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
1592023-11-30T14:14:41 <hebasto> #26762 seems almost rtm?
1602023-11-30T14:14:43 <gribble> https://github.com/bitcoin/bitcoin/issues/26762 | bugfix: Make `CCheckQueue` RAII-styled (attempt 2) by hebasto · Pull Request #26762 · bitcoin/bitcoin · GitHub
1612023-11-30T14:14:53 <achow101> _aj_: maflcko: done
1622023-11-30T14:14:58 *** _flood <_flood!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 260 seconds)
1632023-11-30T14:15:02 <maflcko> thanks
1642023-11-30T14:15:10 <theStack> can i have #28336 added?
1652023-11-30T14:15:12 <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
1662023-11-30T14:15:22 <achow101> hebasto: yes, going to try to get to that soon
1672023-11-30T14:15:42 <murch[m]> Chasing concept acks: https://github.com/bitcoin/bitcoin/pull/27877
1682023-11-30T14:15:44 <hebasto> achow101: thanks
1692023-11-30T14:15:45 <achow101> theStack: done
1702023-11-30T14:15:49 <murch[m]> Also, related to my topic later
1712023-11-30T14:15:54 <_aj_> achow101: #28592 should be easy to review, and basically RTM
1722023-11-30T14:15:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28592 | p2p: Increase tx relay rate by ajtowns · Pull Request #28592 · bitcoin/bitcoin · GitHub
1732023-11-30T14:16:35 <achow101> murch[m]: done. _aj_: will look
1742023-11-30T14:16:49 <murch[m]> Thanks
1752023-11-30T14:17:43 <theStack> achow101: thx
1762023-11-30T14:17:59 *** Murch <Murch!~Murch@user/murch> has quit IRC (Quit: Connection closed)
1772023-11-30T14:18:02 <achow101> #topic Deficient coin selection behavior at high feerates (murch[m])
1782023-11-30T14:18:35 <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.
1792023-11-30T14:19:01 <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.
1802023-11-30T14:19:06 <instagibbs> _aj_ might be helpful to know what the potential downsides are to the PR (I have not thought about this stuff deeply)
1812023-11-30T14:19:47 <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.
1822023-11-30T14:19:48 <_aj_> instagibbs: ie, why there's a limit at all?
1832023-11-30T14:20:29 <instagibbs> _aj_ ð
1842023-11-30T14:20:29 <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.
1852023-11-30T14:21:12 <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.
1862023-11-30T14:21:40 <murch[m]> This wallet behavior is unexpected to users and can cause significant unnecessary cost
1872023-11-30T14:22:31 <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?
1882023-11-30T14:23:17 <sipa> concept ack, but the devil is in the details
1892023-11-30T14:23:17 <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
1902023-11-30T14:23:19 <gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus · Pull Request #27877 · bitcoin/bitcoin · GitHub
1912023-11-30T14:23:29 <Sjors[m]> Why don't any of the three algo's come up with a more sane result?
1922023-11-30T14:24:13 <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.
1932023-11-30T14:24:39 <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.
1942023-11-30T14:24:53 <murch[m]> It is by the way my opinion that Knapsack is utterly useless and should be destroyed.
1952023-11-30T14:25:20 <theStack> :D
1962023-11-30T14:25:45 <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.
1972023-11-30T14:25:59 <achow101> ack CoinGrinder, ack delete knapsack :)
1982023-11-30T14:26:36 <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
1992023-11-30T14:27:29 <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
2002023-11-30T14:27:29 <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
2012023-11-30T14:27:31 <gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus · Pull Request #27877 · bitcoin/bitcoin · GitHub
2022023-11-30T14:27:34 <murch[m]> Thanks :)
2032023-11-30T14:28:02 <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
2042023-11-30T14:28:51 <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
2052023-11-30T14:29:09 <murch[m]> Iâll probably be opening a PR with that in the next couple weeks
2062023-11-30T14:29:26 <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)
2072023-11-30T14:29:35 <achow101> murch[m]: have you run simulations with CoinGrinder?
2082023-11-30T14:29:51 <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
2092023-11-30T14:30:10 <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
2102023-11-30T14:30:16 <vasild> is good to spend the 500 small inputs
2112023-11-30T14:30:57 <achow101> vasild: unfortunately we haven't figured out how to accurately predictthefuture
2122023-11-30T14:30:58 <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
2132023-11-30T14:31:08 <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
2142023-11-30T14:31:22 <murch[m]> Feerates have been going below 30â¯sat/vB nightly, and about a month ago were below 15 sat/vB every day
2152023-11-30T14:31:30 <vasild> sipa: yes
2162023-11-30T14:31:36 <murch[m]> When the feerates are high, we should use few UTXOs, but many utxos at low feerates
2172023-11-30T14:31:58 <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
2182023-11-30T14:32:08 <murch[m]> Always using largest first is a terrible strategy, as I have show with my master thesis in 2016
2192023-11-30T14:32:27 <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"
2202023-11-30T14:32:33 <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
2212023-11-30T14:32:47 <_aj_> 500 inputs seems like a lot even when feerates are low
2222023-11-30T14:32:58 <instagibbs> 500 inputs is like.. we need a consolidate rpc
2232023-11-30T14:33:08 <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
2242023-11-30T14:33:22 <_aj_> instagibbs: "sendall"
2252023-11-30T14:33:38 <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.
2262023-11-30T14:33:40 <sipa> vasild: coingrinder in the current PR triggers based on a multiple of the long-term feerate estimate
2272023-11-30T14:33:50 <instagibbs> _aj_ that is triggered by utxo health metric or something :P
2282023-11-30T14:34:34 <_aj_> instagibbs: "bitcoin-cli wallet-wizard" - evaluates the health of your wallet utxos, and autoconsolidates
2292023-11-30T14:34:40 <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"
2302023-11-30T14:35:10 <sipa> instagibbs: if we'd have a wallet health metric we could optimize for it directly
2312023-11-30T14:35:51 <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
2322023-11-30T14:36:19 <sipa> i guess that is a bug, though not a regression
2332023-11-30T14:36:41 <achow101> I think we've known about this bug for about a decade
2342023-11-30T14:37:02 <_aj_> murch[m]: bug/misfeature, sure
2352023-11-30T14:37:10 <sipa> well i think it has become more concrete - it's been known since forever that coin selection is suboptimal
2362023-11-30T14:37:21 <fjahr> what sipa said, yes, but the devil is in the details
2372023-11-30T14:37:38 <sipa> but "it's spending two orders more UTXOs than necessary at very high feerate" is still something else than "suboptimal"
2382023-11-30T14:38:47 <_aj_> sipa: "do your utxo sizes follow a log-normal distribution" would be my guess at a metric
2392023-11-30T14:39:08 <murch[m]> Yeah, personally Iâd be pretty pissed if my wallet spent 25â¯mBTC in fees more than necessary.
2402023-11-30T14:40:07 <achow101> #topic Stratum v2 (Sjors[m])
2412023-11-30T14:40:29 <Sjors[m]> Basically I plan to take over #27854
2422023-11-30T14:40:32 <gribble> https://github.com/bitcoin/bitcoin/issues/27854 | [WIP] add a stratum v2 template provider by ccdle12 · Pull Request #27854 · bitcoin/bitcoin · GitHub
2432023-11-30T14:40:43 <Sjors[m]> I already managed to rebase it, will make a PR shortly.
2442023-11-30T14:40:55 <sipa> Sjors[m]: oh cool
2452023-11-30T14:40:55 <Sjors[m]> And then actually try understand what it's doing and read the spec :-)
2462023-11-30T14:41:14 <Sjors[m]> I have a little vintage s9 to test with too.
2472023-11-30T14:41:41 <achow101> have you talked to the original author?
2482023-11-30T14:42:52 <Sjors[m]> Nobody has in the past several months unfortunately
2492023-11-30T14:43:01 <Sjors[m]> I did talk to the Stratum v2 folks on their discord.
2502023-11-30T14:43:14 <Sjors[m]> There's a newer branch by Fi3 that I'm starting from.
2512023-11-30T14:43:24 <sipa> Sjors[m]: i'd at least comment on the PR to announce your intention
2522023-11-30T14:43:47 <fjahr> apparently jonatack spoke with them: https://github.com/bitcoin/bitcoin/issues/28642#issuecomment-1765248677
2532023-11-30T14:44:37 <Sjors[m]> Yes, and we can even leave that PR open for a bit.
2542023-11-30T14:45:00 <fanquake> sounds like someone has spoken to them in the past several months then?
2552023-11-30T14:45:05 <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."
2562023-11-30T14:45:13 <fanquake> what's the impetus to take the PR over?
2572023-11-30T14:45:45 <fanquake> Or is the above no-longer true, and the author no-longer working on it?
2582023-11-30T14:45:59 <Sjors[m]> fanquake: Pavlenex asking me to
2592023-11-30T14:46:36 <achow101> fanquake: he hasn't really responded to any of the previously left review
2602023-11-30T14:47:32 <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.
2612023-11-30T14:47:51 <sipa> yeah, i think it'd be good to discuss the plan, whatever it is, on the currently open PR
2622023-11-30T14:48:23 <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
2632023-11-30T14:48:43 <Sjors[m]> Miscommnication is certainly possible.
2642023-11-30T14:48:49 <sipa> but the lack of activity is worrying
2652023-11-30T14:48:50 *** marcofleon <marcofleon!~marcofleo@87.125.242.19> has joined #bitcoin-core-dev
2662023-11-30T14:48:55 <Sjors[m]> I'll leave a link to my branch on that PR and wait to see what happens.
2672023-11-30T14:49:32 <achow101> any other topics to discuss?
2682023-11-30T14:49:43 <Sjors[m]> This is the branch people are currently testing with: https://github.com/bitcoin/bitcoin/compare/master...Fi3:bitcoin:PatchTemplates
2692023-11-30T14:50:15 <Sjors[m]> Last commit from original author on that one is Oct 26, which isn't ages agao.
2702023-11-30T14:50:36 <sipa> right
2712023-11-30T14:52:14 <achow101> #endmeeting
2722023-11-30T14:52:47 *** kashifs <kashifs!~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com> has quit IRC (Quit: Client closed)
2732023-11-30T14:52:48 *** guest-127 <guest-127!~guest-127@212.129.84.94> has quit IRC (Quit: Client closed)
2742023-11-30T14:53:21 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7bc8c5312bf5...c4d47d2c22fc
2752023-11-30T14:53:22 <bitcoin-git> bitcoin/master 66c4b58 fanquake: guix: switch from guix environment to guix shell
2762023-11-30T14:53:22 <bitcoin-git> bitcoin/master c4d47d2 fanquake: Merge bitcoin/bitcoin#26077: guix: switch from `guix environment` to `guix...
2772023-11-30T14:53:55 <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
2782023-11-30T14:55:19 <pinheadmz> #27375 has an ACK from vasild, willcl-ark_ and maflcko any time to rereview this week?
2792023-11-30T14:55:23 <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
2802023-11-30T15:01:09 <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
2812023-11-30T15:01:10 <fjahr> be easy but are there plans to go into this direction in the future?
2822023-11-30T15:02:48 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c4d47d2c22fc...d80318d21110
2832023-11-30T15:02:49 <bitcoin-git> bitcoin/master fafcee4 MarcoFalke: ci: Rename test script to 03_test_script.sh
2842023-11-30T15:02:49 <bitcoin-git> bitcoin/master fad82fe MarcoFalke: ci: Reduce use of bash -c
2852023-11-30T15:02:50 <bitcoin-git> bitcoin/master d80318d fanquake: Merge bitcoin/bitcoin#28954: ci: Reduce use of bash -c
2862023-11-30T15:02:55 <bitcoin-git> [bitcoin] fanquake merged pull request #28954: ci: Reduce use of bash -c (master...2311-ci-) https://github.com/bitcoin/bitcoin/pull/28954
2872023-11-30T15:04:04 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d80318d21110...05d3f8e82228
2882023-11-30T15:04:04 <bitcoin-git> bitcoin/master e67634e Sebastian Falbesoner: fuzz: BIP324: damage ciphertext/aad in full byte range
2892023-11-30T15:04:05 <bitcoin-git> bitcoin/master 05d3f8e fanquake: Merge bitcoin/bitcoin#28951: fuzz: BIP324: damage ciphertext/aad in full b...
2902023-11-30T15:04:10 <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
2912023-11-30T15:05:58 <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/05d3f8e82228...c7f0e9738337
2922023-11-30T15:05:59 <bitcoin-git> bitcoin/master 2d2ef2f Hennadii Stepanov: msvc: No need to specify the default feature for `libevent` package
2932023-11-30T15:06:00 <bitcoin-git> bitcoin/master 1f97e51 Hennadii Stepanov: msvc: Update vcpkg manifest baseline up to "2023.08.09 Release"
2942023-11-30T15:06:00 <bitcoin-git> bitcoin/master 6d05c4f Hennadii Stepanov: msvc: Specify `boost-date-time` package explicitly
2952023-11-30T15:06:05 <bitcoin-git> [bitcoin] fanquake merged pull request #28938: msvc: Update vcpkg manifest (master...231125-vcpkg) https://github.com/bitcoin/bitcoin/pull/28938
2962023-11-30T15:07:06 <vasild> fjahr: indeed! I totally agree
2972023-11-30T15:08:18 *** darosior <darosior!~darosior@109.205.214.46> has quit IRC (Ping timeout: 252 seconds)
2982023-11-30T15:08:52 <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.)
2992023-11-30T15:09:22 *** theStack <theStack!~theStack@95.179.145.232> has quit IRC (Quit: theStack)
3002023-11-30T15:09:30 *** theStack <theStack!~theStack@95.179.145.232> has joined #bitcoin-core-dev
3012023-11-30T15:10:00 <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)
3022023-11-30T15:10:01 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7f0e9738337...cdb772313c03
3032023-11-30T15:10:02 <bitcoin-git> bitcoin/master a4980da fanquake: guix: remove input labels
3042023-11-30T15:10:03 <bitcoin-git> bitcoin/master cdb7723 fanquake: Merge bitcoin/bitcoin#28965: guix: remove input labels
3052023-11-30T15:10:09 <bitcoin-git> [bitcoin] fanquake merged pull request #28965: guix: remove input labels (master...guix_drop_input_label) https://github.com/bitcoin/bitcoin/pull/28965
3062023-11-30T15:11:32 *** darosior <darosior!~darosior@109.205.214.46> has joined #bitcoin-core-dev
3072023-11-30T15:11:45 <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
3082023-11-30T15:11:47 <_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.
3092023-11-30T15:11:49 <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.
3102023-11-30T15:12:35 <sipa> fjahr: fair enough; i think something similar can be achieved by just offering an explicit consolidation option too
3112023-11-30T15:13:08 <vasild> a slider with "cheap" on one end and "consolidate" at the other end
3122023-11-30T15:13:10 <sipa> fjahr: i don't think the 500 inputs issue is due to not knowing long-term feerate
3132023-11-30T15:13:29 <fjahr> sipa: yeah, that would be the most simple option, but maybe there are more user friendly ideas
3142023-11-30T15:13:43 <sipa> we *have* a long-term feerate, it's not particularly sophisticated, but it does something
3152023-11-30T15:14:04 <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
3162023-11-30T15:14:12 <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
3172023-11-30T15:14:36 <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
3182023-11-30T15:15:26 <sipa> fjahr: we run multiple coin selection algorithms, and then pick the best one we found, according to the waste metric
3192023-11-30T15:16:13 <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
3202023-11-30T15:16:51 <sipa> adding a coin selection algorithm that minimizes the number of inputs would be considered much better
3212023-11-30T15:17:16 <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
3222023-11-30T15:20:57 <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.
3232023-11-30T15:21:26 <fjahr> *when that new algo is added
3242023-11-30T15:21:30 <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
3252023-11-30T15:21:43 *** baakeydow <baakeydow!~baake@2001:41d0:203:b12c::> has joined #bitcoin-core-dev
3262023-11-30T15:21:58 <sipa> fjahr: my point is that the current problem is not due to not knowing long-term feerate
3272023-11-30T15:22:06 <sipa> that's an independent improvement
3282023-11-30T15:23:31 <fjahr> sipa: ack
3292023-11-30T15:32:05 *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
3302023-11-30T15:35:06 *** marcofleon <marcofleon!~marcofleo@87.125.242.19> has quit IRC (Quit: Connection closed)
3312023-11-30T15:42:58 *** zato <zato!~zato@user/zato> has quit IRC (Read error: Connection reset by peer)
3322023-11-30T15:45:27 *** realies <realies!~realies@user/realies> has joined #bitcoin-core-dev
3332023-11-30T15:46:40 *** zato <zato!~zato@user/zato> has joined #bitcoin-core-dev
3342023-11-30T15:48:44 <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).
3352023-11-30T15:49:12 <sdaftuar> i was just thinking about that issue myself this morning
3362023-11-30T15:50:47 <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.
3372023-11-30T15:51:14 <sdaftuar> probably the performance concern is negligible compared to what we're already doing though.
3382023-11-30T15:53:03 <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
3392023-11-30T15:53:13 <instagibbs> I'm less familiar with this section of the code
3402023-11-30T15:53:15 <sdaftuar> yes i think so
3412023-11-30T15:53:53 <sdaftuar> in a reorg, it's entirely possible that a spend of the EA output could be non-standard to your node
3422023-11-30T15:54:10 <instagibbs> ah yeah, miner mines something non-standard
3432023-11-30T15:54:14 <instagibbs> f.e.
3442023-11-30T15:54:16 <sdaftuar> yep
3452023-11-30T15:54:47 <instagibbs> let's say we're in a priority txn world but your node isn't, could definitely happen
3462023-11-30T15:54:53 <instagibbs> hmm
3472023-11-30T15:54:57 <sdaftuar> although i think glozow made the point somewhere that we'd evict 0-fee transactions, which would also fix that for you\
3482023-11-30T15:55:04 <instagibbs> Oh.... yeah
3492023-11-30T15:55:22 <instagibbs> well, unless a standard spend of *other* outputs are entered
3502023-11-30T15:55:30 <sdaftuar> good point!
3512023-11-30T15:55:35 <instagibbs> so you'd still have the dust
3522023-11-30T15:55:41 <sdaftuar> right, probably we should filter
3532023-11-30T15:56:34 <instagibbs> if we get this wrong, probably still mostly ok in that these anchors could be cleaned up by a nice miner ð
3542023-11-30T15:56:56 <instagibbs> but I agree, err on cleanliness
3552023-11-30T15:57:30 <_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?
3562023-11-30T16:03:29 <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.
3572023-11-30T16:04:46 <_aj_> yeah, just agreeing that it's not a disaster if things go wrong
3582023-11-30T16:08:06 *** instagibbs_ <instagibbs_!uid142535@id-142535.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
3592023-11-30T16:11:07 *** realies <realies!~realies@user/realies> has quit IRC (Quit: ~)
3602023-11-30T16:12:08 <bitcoin-git> [bitcoin] ryanofsky pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/cdb772313c03...ffb021612b8f
3612023-11-30T16:12:09 <bitcoin-git> bitcoin/master fa7eb4f MarcoFalke: fuzz: Drop unused version from fuzz input format
3622023-11-30T16:12:09 <bitcoin-git> bitcoin/master fae00fe MarcoFalke: Remove unused CDataStream
3632023-11-30T16:12:09 <bitcoin-git> bitcoin/master fa0ae22 MarcoFalke: Remove unused SER_NETWORK, SER_DISK
3642023-11-30T16:12:15 <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
3652023-11-30T16:20:51 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has joined #bitcoin-core-dev
3662023-11-30T16:36:12 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
3672023-11-30T16:36:18 *** dviola <dviola!~diego@user/dviola> has quit IRC (Quit: WeeChat 4.1.1)
3682023-11-30T16:49:12 *** Guest56 <Guest56!~Guest75@103.87.236.96> has joined #bitcoin-core-dev
3692023-11-30T16:52:30 *** Guest56 <Guest56!~Guest75@103.87.236.96> has quit IRC (Client Quit)
3702023-11-30T16:52:53 *** Guest18 <Guest18!~Guest75@103.87.236.96> has joined #bitcoin-core-dev
3712023-11-30T16:55:00 <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
3722023-11-30T16:57:26 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
3732023-11-30T17:10:48 *** Guest18 <Guest18!~Guest75@103.87.236.96> has quit IRC (Ping timeout: 250 seconds)
3742023-11-30T17:55:52 <fanquake> We've merged a few Guix related changes into master
3752023-11-30T17:55: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)
3762023-11-30T17:56:21 <fanquake> But if anyone who regular builds, wants to build master / happens to find any issues, please open an issue
3772023-11-30T18:09:07 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3782023-11-30T18:18:39 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has quit IRC (Remote host closed the connection)
3792023-11-30T18:19:11 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has joined #bitcoin-core-dev
3802023-11-30T18:21:16 *** zato <zato!~zato@user/zato> has quit IRC (Quit: Om mani padme hum)
3812023-11-30T18:24:08 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has quit IRC (Ping timeout: 256 seconds)
3822023-11-30T18:40:51 *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
3832023-11-30T18:43:04 <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.
3842023-11-30T18:43:44 <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
3852023-11-30T18:44:21 <instagibbs> mmm right
3862023-11-30T18:44:32 *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 256 seconds)
3872023-11-30T18:44:34 <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?
3882023-11-30T18:45:09 <sdaftuar> that seems somewhat tedious
3892023-11-30T18:46:07 <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)
3902023-11-30T18:47:37 <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
3912023-11-30T18:48:08 <instagibbs> > later, a higher feerate spend of the non-EA output is added
3922023-11-30T18:48:08 <instagibbs> that's two descendants of parent?
3932023-11-30T18:48:09 <sdaftuar> so that's parent P, child C1 (EA spend) and child C2 (non-EA spend)
3942023-11-30T18:48:32 <sdaftuar> P+C1 is added to the mempool initially; later C2 is added also spending another output of P.
3952023-11-30T18:49:51 <sdaftuar> C1 could be removed from the mempool due to eviction or RBF, for that matter
3962023-11-30T18:50:01 <instagibbs> you can't have two descendants of parent
3972023-11-30T18:50:02 <instagibbs> it's v3
3982023-11-30T18:50:23 <sdaftuar> ahh, ok
3992023-11-30T18:50:31 <instagibbs> and any child MUST\ spend the anchor
4002023-11-30T18:50:35 <instagibbs> """sibling eviction"""
4012023-11-30T18:51:03 <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
4022023-11-30T18:51:22 <murch[m]> fjahr: You can configure the long term feerate estimate, which would change the behavior in that manner
4032023-11-30T18:52:12 <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).
4042023-11-30T18:52:25 <sdaftuar> and then it's just in the reorg case where that last property might not hold
4052023-11-30T18:52:27 <instagibbs> ð
4062023-11-30T18:52:36 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has joined #bitcoin-core-dev
4072023-11-30T18:52:42 <instagibbs> right now it gets evicted in reorg, but even in the case where it has a spend
4082023-11-30T18:52:55 <instagibbs> (I need a test for this, heh)
4092023-11-30T18:53:21 <sdaftuar> right, and with the bypass_limits extension we can fix that i guess
4102023-11-30T18:54:48 <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
4112023-11-30T18:55:30 <murch[m]> Yet, even though we currently treat 75â¯s/vB as a high feerate, the input set selection doesnât reflect that information
4122023-11-30T18:59:14 <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
4132023-11-30T18:59:19 <instagibbs> nice
4142023-11-30T19:00:04 <instagibbs> well, except reorgs ð¬
4152023-11-30T19:01:19 *** salvatoshi <salvatoshi!~salvatosh@194.65.48.125> has quit IRC (Ping timeout: 260 seconds)
4162023-11-30T19:13:45 *** salvatoshi <salvatoshi!~salvatosh@2001:818:e733:2700:a0eb:63f:e256:da39> has joined #bitcoin-core-dev
4172023-11-30T19:15:26 *** boris- <boris-!~boris@201.189.64.198> has joined #bitcoin-core-dev
4182023-11-30T19:17:20 *** pablomartin <pablomartin!~pablomart@103.50.33.51> has joined #bitcoin-core-dev
4192023-11-30T19:28:35 *** benwestgate <benwestgate!~BenWestga@2603-8080-74f0-e960-8b9f-e9eb-cc22-8be1.res6.spectrum.com> has quit IRC (Quit: Leaving.)
4202023-11-30T19:29:13 <bitcoin-git> [bitcoin] achow101 pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/ffb021612b8f...498994b6f55d
4212023-11-30T19:29:14 <bitcoin-git> bitcoin/master be4ff30 Hennadii Stepanov: Move global `scriptcheckqueue` into `ChainstateManager` class
4222023-11-30T19:29:15 <bitcoin-git> bitcoin/master d03eaac Hennadii Stepanov: Make `CCheckQueue` destructor stop worker threads
4232023-11-30T19:29:15 <bitcoin-git> bitcoin/master 9cf89f7 Hennadii Stepanov: refactor: Make `CCheckQueue` constructor start worker threads
4242023-11-30T19:29:17 *** martinus <martinus!~martinus@2001:4bc9:802:1325:ce4:a0d6:761e:5> has joined #bitcoin-core-dev
4252023-11-30T19:29:21 <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
4262023-11-30T19:30:39 *** kashifs <kashifs!~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com> has joined #bitcoin-core-dev
4272023-11-30T19:30:45 *** kashifs <kashifs!~kashifs@2603-7000-4600-0500-6d6d-cba3-f0c0-2f75.res6.spectrum.com> has quit IRC (Client Quit)
4282023-11-30T19:46:37 *** benwestgate <benwestgate!~BenWestga@035-146-116-233.res.spectrum.com> has joined #bitcoin-core-dev
4292023-11-30T19:53:20 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has quit IRC (Remote host closed the connection)
4302023-11-30T19:56:58 *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@146.70.211.124> has quit IRC (Ping timeout: 260 seconds)
4312023-11-30T19:58:44 *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@87.249.134.39> has joined #bitcoin-core-dev
4322023-11-30T20:07:58 <jonatack> Sjors[m]: cool, would be good to see progress on stratum v2. I sent a message linking to today's discussion.
4332023-11-30T20:11:02 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
4342023-11-30T20:11:35 <jonatack> murch[m]: thank you for the reminder about the coingrinder pull
4352023-11-30T20:11:44 *** kevkevin <kevkevin!~kevkevin@c-73-111-168-5.hsd1.il.comcast.net> has joined #bitcoin-core-dev
4362023-11-30T20:14:19 <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:
4372023-11-30T20:22:12 <_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.
4382023-11-30T20:24:39 <_aj_> jonatack: also, #28318...
4392023-11-30T20:24:41 <gribble> https://github.com/bitcoin/bitcoin/issues/28318 | logging: Simplify API for level based logging by ajtowns · Pull Request #28318 · bitcoin/bitcoin · GitHub
4402023-11-30T20:26:44 *** pablomartin <pablomartin!~pablomart@103.50.33.51> has quit IRC (Ping timeout: 255 seconds)
4412023-11-30T20:27:28 <jonatack> _aj_: yes, that pull is on my list, i've been prioritising the p2p bugfixes but will get there, ty for the reminder
4422023-11-30T20:28:39 <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)
4432023-11-30T20:29:37 <jonatack> i don't have the habit of looking in delving yet but have opened it a few times
4442023-11-30T20:29:47 *** pablomartin <pablomartin!~pablomart@193.160.246.221> has joined #bitcoin-core-dev
4452023-11-30T20:35:54 <sipa> fwiw, delving is also archived
4462023-11-30T20:42:23 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has joined #bitcoin-core-dev
4472023-11-30T20:53:29 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
4482023-11-30T20:53:36 *** BlueMatt[m] <BlueMatt[m]!~bluematt@2620:6e:a000:ce11::d> has joined #bitcoin-core-dev
4492023-11-30T20:53:36 <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
4502023-11-30T20:53:56 <_aj_> they can be ambiguous, yeah
4512023-11-30T20:53:59 <BlueMatt[m]> rust-bitcoin deliberately encodes 0-input transactions with the marker bytes because it resolves the ambiguity
4522023-11-30T20:54:08 <BlueMatt[m]> if you have the marker bytes its not ambiguous
4532023-11-30T20:54:27 <jonatack> Sjors[m]: discussed with moneyball____ and he said they haven't been getting updated, "So Sjors bless his heart is helping"
4542023-11-30T20:54:48 <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 :(
4552023-11-30T20:55:21 <_aj_> there's an "iswitness" flag for decoderawtransaction that you can use if you know they've been encoded with witness flag?
4562023-11-30T20:55:37 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has joined #bitcoin-core-dev
4572023-11-30T20:56:16 <sipa> BlueMatt[m]: BIP144 says you cannot use the extended encoding if there are no witnesses
4582023-11-30T20:56:32 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has quit IRC (Client Quit)
4592023-11-30T20:56:38 <BlueMatt[m]> yes, but BIP144 is about consensus, and these are not consensus :p
4602023-11-30T20:56:46 <BlueMatt[m]> _aj_: ah, that's helpful, thanks
4612023-11-30T20:57:12 *** Guest77 <Guest77!~Guest41@2600:6c60:57f0:b20:a14c:441b:6c51:65fa> has joined #bitcoin-core-dev
4622023-11-30T20:58:22 <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
4632023-11-30T20:58:48 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has joined #bitcoin-core-dev
4642023-11-30T20:58:53 <sipa> BlueMatt[m]: no, BIP144 is P2P protocol; though fair enough, RPC isn't P2P either
4652023-11-30T20:59:13 <Sjors[m]> jonatack: thanks, I'll take a look tomorrow or Monday
4662023-11-30T20:59:13 *** Guest77 <Guest77!~Guest41@2600:6c60:57f0:b20:a14c:441b:6c51:65fa> has quit IRC (Client Quit)
4672023-11-30T20:59:15 <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"
4682023-11-30T20:59:27 <BlueMatt[m]> which would imply that setting the marker bytes is more likely to resolve correctly
4692023-11-30T20:59:32 <BlueMatt[m]> but i guess thats not what it does?
4702023-11-30T20:59:57 <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
4712023-11-30T21:00:02 <_aj_> there's other heuristics like is the output amount sensible iirc
4722023-11-30T21:01:17 <BlueMatt[m]> sipa: I mean in general it seems like modern software really should be setting the marker bytes, exactly to avoid the ambiguity.
4732023-11-30T21:01:29 <sipa> BlueMatt[m]: nacl
4742023-11-30T21:01:30 <sipa> nack
4752023-11-30T21:01:32 <BlueMatt[m]> _aj_: ah, fair, but in any case that seems to imply it should work fine with zero-input-marker-bytes
4762023-11-30T21:01:39 <BlueMatt[m]> sipa: can you elaborate :)
4772023-11-30T21:01:52 <_aj_> nah, sipa's right; CTransaction deserialize just fails in that case
4782023-11-30T21:02:10 <BlueMatt[m]> right, okay, so ignoring for a moment what it does, what should it do :)
4792023-11-30T21:02:30 <sipa> i think it does the right thing
4802023-11-30T21:02:59 <BlueMatt[m]> yes, so I've provided my justification, please provide yours, then lets talk about the relative tradeoffs :)
4812023-11-30T21:03:08 <bitcoin-git> [bitcoin] achow101 opened pull request #28976: Migrate blank (master...migrate-blank) https://github.com/bitcoin/bitcoin/pull/28976
4822023-11-30T21:03:11 <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
4832023-11-30T21:03:28 <_aj_> could add a special case for !tx.HasWitness() && tx.vin.size() == 0
4842023-11-30T21:03:38 <sipa> i strongly disagree with having multiple encodings for the same data
4852023-11-30T21:04:05 *** ___nick___ <___nick___!~quassel@host81-129-235-34.range81-129.btcentralplus.com> has quit IRC (Ping timeout: 240 seconds)
4862023-11-30T21:04:07 <_aj_> better than than different data having the same encoding?
4872023-11-30T21:04:27 <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
4882023-11-30T21:04:36 <sipa> i mean... why do you have transactions with 0 inputs anyway?
4892023-11-30T21:04:51 <BlueMatt[m]> cause people havent yet adopted psbt universally, sadly
4902023-11-30T21:06:22 <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 :)
4912023-11-30T21:06:24 <_aj_> https://github.com/bitcoin/bitcoin/pull/17775#issuecomment-580584699 hah
4922023-11-30T21:06:30 <BlueMatt[m]> so long-term we'd end up with one encoding
4932023-11-30T21:07:03 <BlueMatt[m]> ah! its instagibbs' fault
4942023-11-30T21:07:18 <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?
4952023-11-30T21:07:37 <BlueMatt[m]> that's what rust-bitcoin does
4962023-11-30T21:07:51 <_aj_> or we could say the correct format is psbt :)
4972023-11-30T21:07:53 <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
4982023-11-30T21:07:56 <BlueMatt[m]> cause we didnt want to deal with the ambiguity (which usually requires retrying deserialization to resolve, which is annoying)
4992023-11-30T21:08:05 <BlueMatt[m]> sipa: fair enough, yes, that makes sense
5002023-11-30T21:08:16 <BlueMatt[m]> _aj_: ha, well if you read the rust-bitcoin issue that was also the response lol
5012023-11-30T21:09:39 <sipa> let me see how much breaks if i change that
5022023-11-30T21:10:03 *** phantomcircuit_ <phantomcircuit_!~phantomci@2604:a880:1:20::f2:c001> has quit IRC (Quit: ZNC - https://znc.in)
5032023-11-30T21:12:45 <BlueMatt[m]> yea, indeed, rust-bitcoin will reject transactions serialized with > 0 inputs with no witnesses
5042023-11-30T21:12:52 <BlueMatt[m]> https://github.com/rust-bitcoin/rust-bitcoin/blob/master/bitcoin/src/blockdata/transaction.rs#L1102
5052023-11-30T21:13:13 <achow101> BlueMatt[m]: have you heard about our lord and savior psbt?
5062023-11-30T21:13:40 <sipa> achow101: he has, but apparently some of his users haven't seen The Light yet.
5072023-11-30T21:14:03 <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 :)
5082023-11-30T21:22:02 *** phantomcircuit <phantomcircuit!~phantomci@2604:a880:1:20::f2:c001> has joined #bitcoin-core-dev
5092023-11-30T21:26:09 <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
5102023-11-30T21:27:05 <bitcoin-git> [bitcoin] ryanofsky opened pull request #28978: doc: Add multiprocess design doc (master...pr/ipcdoc) https://github.com/bitcoin/bitcoin/pull/28978
5112023-11-30T21:31:56 *** Guyver2_ <Guyver2_!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev
5122023-11-30T21:39:48 <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
5132023-11-30T21:40:05 <instagibbs> BlueMatt[m] I remember literally none of this
5142023-11-30T21:41:28 <murch[m]> cc: fjahr, Sjors, vasild, instagibbs
5152023-11-30T21:41:56 <instagibbs> I need a gutter guard, how did you know
5162023-11-30T21:42:19 *** martinus <martinus!~martinus@2001:4bc9:802:1325:ce4:a0d6:761e:5> has quit IRC (Quit: Konversation terminated!)
5172023-11-30T21:43:28 <murch[m]> Iâll add some simulations by next week
5182023-11-30T21:46:56 <BlueMatt[m]> <instagibbs> "Matt Corallo I remember literall..." <- convenient excuse
5192023-11-30T21:49:42 *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
5202023-11-30T21:54:04 *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 276 seconds)
5212023-11-30T22:05:38 *** kevkevin <kevkevin!~kevkevin@c-73-111-168-5.hsd1.il.comcast.net> has quit IRC (Remote host closed the connection)
5222023-11-30T22:26:23 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.1.1)
5232023-11-30T22:30:49 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has joined #bitcoin-core-dev
5242023-11-30T22:35:38 *** kevkevin <kevkevin!~kevkevin@2601:243:197e:8f10:a016:8982:f255:486e> has quit IRC (Ping timeout: 268 seconds)
5252023-11-30T22:47:26 *** pablomartin <pablomartin!~pablomart@193.160.246.221> has quit IRC (Ping timeout: 245 seconds)
5262023-11-30T22:53:24 *** pablomartin <pablomartin!~pablomart@193.160.246.224> has joined #bitcoin-core-dev
5272023-11-30T22:55:27 *** benwestgate <benwestgate!~BenWestga@035-146-116-233.res.spectrum.com> has quit IRC (Quit: Leaving.)
5282023-11-30T22:56:43 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
5292023-11-30T22:59:07 <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
5302023-11-30T22:59:32 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Ping timeout: 252 seconds)
5312023-11-30T23:07:17 *** raini_ok <raini_ok!~raini_ok@user/raini-ok/x-7871157> has joined #bitcoin-core-dev
5322023-11-30T23:13:39 *** pablomartin <pablomartin!~pablomart@193.160.246.224> has quit IRC (Ping timeout: 256 seconds)
5332023-11-30T23:41:21 *** Guest16 <Guest16!~Guest16@108-77-84-183.lightspeed.rlghnc.sbcglobal.net> has joined #bitcoin-core-dev
5342023-11-30T23:43:32 *** Guest16 <Guest16!~Guest16@108-77-84-183.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Client Quit)