--- Log opened Thu Dec 15 00:00:45 2022
00:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
00:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:21 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
00:23 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:26 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
00:42 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
01:22 -!- demono [~demono@77.109.165.235] has joined #bitcoin-core-dev
01:25 -!- sgiath [~sgiath@mail.sgiath.dev] has quit [Ping timeout: 255 seconds]
01:25 -!- sgiath [~sgiath@2a02:25b0:aaaa:aaaa:a3c3:ed4b:6b06:0] has joined #bitcoin-core-dev
01:29 -!- demono [~demono@77.109.165.235] has quit [Quit: Client closed]
02:27 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
02:27 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
02:43 < bitcoin-git> [bitcoin] fanquake opened pull request #26704: doc: add 22.1 release notes (master...historical_rel_notes_22_1) https://github.com/bitcoin/bitcoin/pull/26704
03:00 -!- bomb-on [~bomb-on@user/bomb-on] has joined #bitcoin-core-dev
03:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c9ac:9d5c:7309:a398] has joined #bitcoin-core-dev
03:39 -!- infernix [nix@spirit.infernix.net] has quit [Quit: ZNC - http://znc.sourceforge.net]
04:10 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ba47a4ba97e9...9a72119e7e27
04:10 < bitcoin-git> bitcoin/master fa34e5f MarcoFalke: test: Avoid intermittent timeout in feature_assumevalid.py
04:10 < bitcoin-git> bitcoin/master 9a72119 MarcoFalke: Merge bitcoin/bitcoin#26651: test: Avoid intermittent timeout in feature_a...
04:10 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #26651: test: Avoid intermittent timeout in feature_assumevalid.py (master...2212-test-fix-assumevalid-🌞) https://github.com/bitcoin/bitcoin/pull/26651
04:19 -!- infernix [nix@spirit.infernix.net] has joined #bitcoin-core-dev
04:36 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9a72119e7e27...03708dac0ac6
04:36 < bitcoin-git> bitcoin/master 062e4e9 fanquake: doc: add 22.1 release notes
04:36 < bitcoin-git> bitcoin/master 03708da MarcoFalke: Merge bitcoin/bitcoin#26704: doc: add 22.1 release notes
04:36 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #26704: doc: add 22.1 release notes (master...historical_rel_notes_22_1) https://github.com/bitcoin/bitcoin/pull/26704
04:50 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
04:54 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
05:05 -!- vasild [~vd@user/vasild] has quit [Quit: leaving]
05:36 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:48 -!- Hercules1 [~Hercules@ti0018a400-7782.bb.online.no] has joined #bitcoin-core-dev
05:52 -!- Hercules1 [~Hercules@ti0018a400-7782.bb.online.no] has quit [Quit: Leaving]
05:59 -!- jtraub91 [~jason@c-76-111-232-173.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
06:08 -!- x22x22x [~x88x88x@2001:19f0:5:39a8:5400:3ff:feb6:73cb] has quit [Ping timeout: 252 seconds]
06:10 < sdaftuar> jamesob: i don't know exactly what use case you're thinking of but I would imagine that rule #4 pinning could also come up in that situation
06:10 <@gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
06:13 < sdaftuar> i'm imagining that someone creates a large, very low-fee transaction in the mempool (txA), with a small low-feerate child txB.  you create your transaction C and broadcast it, and an adversary could then construct txD that conflicts with B and C, which has txA as a parent.
06:14 < darosior> jamesob: also rule2 since you are using ACP, a replacement with a lower ancestor feerate could be accepted. See https://github.com/bitcoin/bitcoin/pull/23121#issuecomment-929475999.
06:14 < sdaftuar> txD might be very high individual feerate, but relatively low mining score -- and if you try to rebroadcast your own feebump of C which will conflict with txD, you'll have to pay the very high feerate
06:16 -!- freesprung [~freesprun@user/freesprung] has quit [Ping timeout: 256 seconds]
06:18 < darosior> (for rule2 it's not really pinning per se, i don't know how we could name it)
06:23 < sdaftuar> i guess conceptually what i described is no different from rule #3 pinning, in terms of economic effect
06:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
06:27 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:28 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
06:32 < instagibbs> darosior, the use case in mind I don't think requires new unconfirmed outputs, which is why I think its on the order of rule 3 pinning
06:33 < darosior> instagibbs: but if you sign with SINGLE|ACP a third party can always add some whether you need them or not
06:33 < instagibbs> *they* can pin themself via rule 2... sure
06:34 < instagibbs> honest party just won't source unconfirmed inputs, in this scenario at least
06:35 < instagibbs> (does not generalize I know)
06:35 < darosior> instagibbs: i don't understand. If you make a transaction with a >1sat/vb feerate that you sign with SINGLE|ACP i can attach an unconfirmed input to your transaction thereby decreasing its ancestor feerate. You don't pin yourself, i pin you.
06:36 < instagibbs> that's on the same order as rule 3 pin, no?
06:36 < instagibbs> nothing to do with rule 2
06:36 < instagibbs> s/rule 3/economic pin/ maybe
06:37 < instagibbs> I don't think we're disagreeing :)
06:37 -!- freesprung [~freesprun@user/freesprung] has joined #bitcoin-core-dev
06:40 < glozow> generally the problem with anyonecanpay = anyonecanrbf, adding low feerate ancestor. it’s the same economical pin ie you can add 100ksat to the replacement cost. but the difference is the attack scales; you can use the same ancestor for many of these attacks
06:41 < sdaftuar> depending on how large the victim's transaction is compared to what an attacker would need to do, the feerate attack could be made worse than the total-fee attack, but i'm not sure how much it matters.
06:43 < sdaftuar> ie if the victim is broadcasting a 3-input, 3-output transaction (each one SINGLE |ACP), that can be split up into three separate attack packages, which might be worse news for the victim
06:43 < sdaftuar> glozow:good point on the scaling effect!
06:43 < instagibbs> oh, these are bizarre uses lol
06:43 < instagibbs> yeah very interesting point glozow 
06:46 < instagibbs> sdaftuar, in general I'm assuming people aren't doing batching, or if they are, they don't care about confirmation speed....
06:57 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has joined #bitcoin-core-dev
06:59 -!- b10c [~quassel@user/b10c] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
07:01 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has joined #bitcoin-core-dev
07:01 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has quit [Changing host]
07:01 -!- b10c [~quassel@user/b10c] has joined #bitcoin-core-dev
07:10 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
07:15 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 264 seconds]
07:17 < jamesob> sdaftuar: yes, the case you highlight (where you have n input-output pairs each signed SINGLE|ACP) I think can be unbundled and griefed individually, and because of the no-new-unconfirmed-inputs RBF rule, have to be bumped individually by the victim, wasting a lot of fees
07:17 < jamesob> but I think fundamentally, all of this boils down to rule #3-style griefing, _not_ strict pinning
07:17 <@gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
07:21 < sdaftuar> jamesob: the no-new-unconfirmed-inputs rule is not very effective, because if you want to introduce a new unconfirmed input for a replacement transaction, you can work around it by just conflicting with a transaction that has the ancestor you want to include
07:22 < sdaftuar> for instance the example i wrote above shows how to do that (txD replaces txB and txC, and from C's perspective is introducing a "new" unconfirmed input)
07:23 < instagibbs> I mean, it also is worked around by being "first"
07:24 < sdaftuar> instagibbs: even if there is no SINGLE|ACP batching going on, I assume a transaction that has a SINGLE|ACP input probably also has other inputs and outputs as well, for instance you'd need to if you were going to feebump?
07:25 < instagibbs> given today's policy(no package CPFP_, likely
07:25 < jamesob> instagibbs: right, but you can't ever really rely on being "first" given mempool mapping/frontrunning
07:25 < instagibbs> it's a incentive compat vs pinning tension I guess
07:26 < sdaftuar> i think as soon as the victim's transaction is bigger than a 2-in, 2-out transaction, then the most effective pin becomes based on feerate rather than fee, i think
07:28 < instagibbs> it's essentially a pinning multiplier on top of rule3 pin, if you're batching these state updates
07:28 < instagibbs> state update == the inputs and updates that cannot be separated due to sighash coverage... need a better term for this
07:33 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 252 seconds]
07:33 -!- _Sam-- [~sam@52.152.220.68] has joined #bitcoin-core-dev
07:34 < bitcoin-git> [bitcoin] hebasto opened pull request #26705: clang-tidy: Check headers and fixes them (master...221215-tidy) https://github.com/bitcoin/bitcoin/pull/26705
07:35 < instagibbs> ok sdaftuar's point is that if your adversary can BYOF more compactly than you, it increases the pin
07:35 < instagibbs> corollary is that if your attacker doesn't have chunky utxos they can't pin as much
07:36 < sdaftuar> instagibbs: ah but in this particular case, the attacker can construct a "chunky" utxo with the large unconfirmed ancestor
07:37 < sdaftuar> at least potnetially
07:37 < instagibbs> that's fine, I'm assuming we're maxing out package size here
07:38 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
07:39 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
07:41 < jamesob> So is the idea of "large ancestor being reused to grief multiple RBFable ACP pairs" just that any RBFable ACP pair can be reformulated and bumped with the large ancestor add as an input by the attacker at will, or is it something more nuanced?
07:42 < jamesob> (where reformulated = packed into a new transaction by griefer)
07:44 < glozow> jamesob: yep. acp + rbf = anyone can bump you down
07:44 < instagibbs> so I think the key is this additional pinning multiplier only exists with ancestral junk (just clear to me now)
07:45 < sdaftuar> jamesob: it may be also worth noting that an adversary can also keep your transaction out of the mempool. costliness is determined by the incentive compatibility problems we have with our current RBF scheme
07:46 < sdaftuar> naively: you send a transaction, i conflict it, and then i conflict that version in a way that drops your input.
07:46 < sdaftuar> if you are paying attention you can rebroadcast, but i think it might not relay due to bandwidth optimizations
07:46 < sdaftuar> (for a while)
07:47 < sdaftuar> or you can broadcast an alternate version of your transaction, and the adversary can play the same game
07:47 < sdaftuar> morally speaking it should be expensive for the attacker to do this, but it may not be:
07:48 < sdaftuar> the attacker can take advantage of the bug where we only compare feerates of replacement transactinos with their direct conflicts, to send replacement transactions that have a lower feerate than the transaction containing the victim's input.
07:49 < sdaftuar> (would take some more thought for me to articulate what the cost might end up looking like, but being forced to be vigilant for what is being relayed and in mempools is already sort of bad)
07:52 -!- test__ is now known as _flood
07:58 -!- hg [~halosghos@user/halosghost] has joined #bitcoin-core-dev
07:59 < jamesob> sdaftuar: oh interesting... what are the "bandwidth optimizations" you're talking about there? that sounds like a more severe attack than just fee griefing
08:07 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #26706: doc: Properly report optional RPC args (master...2212-doc-rpc-🐵) https://github.com/bitcoin/bitcoin/pull/26706
08:10 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
08:18 -!- kexkey [~kexkey@static-198-54-132-132.cust.tzulo.com] has joined #bitcoin-core-dev
08:21 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Write error: Connection reset by peer]
08:21 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
08:37 -!- kexkey [~kexkey@static-198-54-132-132.cust.tzulo.com] has quit [Ping timeout: 272 seconds]
08:38 -!- kexkey [~kexkey@static-198-54-132-140.cust.tzulo.com] has joined #bitcoin-core-dev
08:43 -!- gnaf [~gnaf@93-190-140-117.hosted-by-worldstream.net] has joined #bitcoin-core-dev
08:48 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
08:49 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
08:49 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Read error: Connection reset by peer]
08:50 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
08:51 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
08:52 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
08:54 < bitcoin-git> [bitcoin] dhruv closed pull request #24545: BIP324: Enable v2 P2P encrypted transport (master...bip324-enable) https://github.com/bitcoin/bitcoin/pull/24545
08:55 < dhruv> I just made a mistake where i git pushed -d instead of -f and accidentally closed #24545. Can a maintainer help me reopen it?
08:55 <@gribble> https://github.com/bitcoin/bitcoin/issues/24545 | BIP324: Enable v2 P2P encrypted transport by dhruv · Pull Request #24545 · bitcoin/bitcoin · GitHub
08:56 < fanquake> not after you've deleted the branch
08:56 < dhruv> So I need to make a new PR?
08:57 < fanquake> Can you restore the branch
08:57 < dhruv> I did push it back up with the same branch name
08:58 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
08:58 < dhruv> Is that what you mean by restore?
08:58 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
08:59 < fanquake> Ok. I still can't reopen, so you might just have to open a new PR. I think if you've pushed it back up, it has to be the exact same content as prior to close, to be able to re-open.
09:00 < _aj_> yeah, force push back to 8f7714e33804b6cf96fedbe05751d1a700e1e8d1, reopen, then force push again
09:00 < dhruv> ah, ok let me try that.
09:02 < bitcoin-git> [bitcoin] dhruv reopened pull request #24545: BIP324: Enable v2 P2P encrypted transport (master...bip324-enable) https://github.com/bitcoin/bitcoin/pull/24545
09:02 < dhruv> that worked. Thank you fanquake and _aj_!
09:15 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 252 seconds]
09:30 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
09:46 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:47 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
09:49 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:56 -!- jtraub91_ [~jason@2607:fb91:1905:a397:dd76:2a3b:8fbc:f7db] has joined #bitcoin-core-dev
09:56 < sdaftuar> jamesob: we use a rolling bloom filter to prevent re-relaying a transaction to a peer that we think we've already sent it, or that it's already sent us
09:57 < sdaftuar> jamesob: we clear that filter out every time a new block is found, so that's a lower bound on when you could try to re-relay the same transaction and have it propagate
09:57 < sdaftuar> er upper bound
09:59 -!- jtraub91 [~jason@c-76-111-232-173.hsd1.fl.comcast.net] has quit [Ping timeout: 272 seconds]
10:00 -!- jtraub91_ [~jason@2607:fb91:1905:a397:dd76:2a3b:8fbc:f7db] has quit [Ping timeout: 246 seconds]
10:02 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
10:09 -!- b_101_ [~robert@189.236.6.68] has joined #bitcoin-core-dev
10:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
10:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
10:11 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
10:12 < ariard> rebroadcast logic for Lightning time-sensitive transactions are scheduled on block for now, and rebroadcast implies a fee-bumping (either RBF is the transaction is single-party malleable or CPFP is dual-signed)  
10:13 < ariard> so the rolling bloom filter is less an issue than the RBF penalty than you might account for every RBF attempt (that we've hardcoded somewhere in the LDK backend)
10:23 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has quit [Quit: 404]
10:24 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has joined #bitcoin-core-dev
10:37 < sdaftuar> ariard: do the transactions that you're referring to use ACP? if so, then it seems trivial to attack by just knocking it out of the mempool
10:39 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
10:41 -!- b_101_ [~robert@189.236.6.68] has quit [Ping timeout: 268 seconds]
11:01 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:01 < achow101> meeting?
11:01 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
11:01 -!- kmartin [~kmartin@20014C4E24D79A007B45CAFA8A79EA4A.dsl.pool.telekom.hu] has joined #bitcoin-core-dev
11:03 < achow101> Guess I can run it
11:03 < achow101> #startmeeting
11:03 <@core-meetingbot> Meeting started Thu Dec 15 19:03:37 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
11:03 <@core-meetingbot> Available commands: action commands idea info link nick
11:03 < brunoerg> hi
11:04 < lightlike> hi
11:04 < achow101> #bitcoin-core-dev Meeting: achow101 aj amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd 
11:04 < achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
11:04 < vasild> hi
11:04 < kanzure> hi
11:04 < achow101> Welcome to the weekly general IRC meeting
11:05 < LarryRuane> Hi
11:05 < achow101> There is one preproposed meeting topic: https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
11:05 < achow101> any last minute topics to add?
11:06 < achow101> Let's start with the usual
11:06 < achow101> #topic High priority for review
11:06 <@core-meetingbot> topic: High priority for review
11:06 < achow101> https://github.com/orgs/bitcoin/projects/1 anything to add/merge/remove?
11:07 < Murch1> Hi
11:08 < achow101> and also reminder that we now have https://github.com/orgs/bitcoin/projects/5 where people can add their own PRs
11:08 < brunoerg> cool
11:08 -!- as2333 [~as2333@host95.201-252-100.telecom.net.ar] has joined #bitcoin-core-dev
11:10 < achow101> #topic https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
11:10 <@core-meetingbot> topic: https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
11:10 < achow101> #25871
11:10 <@gribble> https://github.com/bitcoin/bitcoin/issues/25871 | contrib: add vasild to trusted keys by vasild · Pull Request #25871 · bitcoin/bitcoin · GitHub
11:11 < vasild> I have no idea what is the status of that, but I am here to answer questions, if any (a bit sleepy, though :)
11:11 < achow101> I think bytes1440000 was wondering what the status of that was
11:11 < b10c> hi
11:13 < achow101> I think the current status is that a few contributors are -0 or -1
11:16 < achow101> and the next steps would be to follow up with those contributors to see if any of the discussion has changed their opinion
11:16 < aureleoules> hi
11:17 < achow101> anything else to discuss?
11:18 < aureleoules> yes
11:18 < aureleoules> I've been experimenting with brunoerg on mutation testing and I would love your feedback
11:18 < vasild> achow101: who are those contributors? there are no NACKs on github, the sole -1 is "-1 on maintaining net processing" from dergoegge but "net processing" was omitted from the scope...
11:19 < vasild> no -0 either
11:19 < achow101> vasild: dergoegge fanquake and jeremyrubin I think
11:20 < achow101> unless I missed a followup comment, but no acks from them either
11:21 < _aj_> are there any PRs that are stalling due to lack of people merging, rather than lack of review or waiting-for-author/rebase?
11:22 < _aj_> (if so, maybe move them to the Ready for merge column in the "PR Statuses" project linked above?)
11:23 < achow101> _aj_: I don't think so. I've been looking at the ack counts of all of the open prs, and the highest is 2, so not particularly certain that those are ready for merging
11:24 < achow101> although some may have had acks until they got conflicted and needed rebasing
11:26 < jeremyrubin> i withdraw all my historical acks or nacks on core prs; don't think that they particularly matter and the maintainers should just do what they see fit to advance the project
11:26 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:27 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
11:28 -!- Talkless [~Talkless@mail.dargis.net] has quit [Client Quit]
11:28 < achow101> doesn't seem like there's much else to say on this topic
11:28 < achow101> #topic mutation testing (aureleoules)
11:28 <@core-meetingbot> topic: mutation testing (aureleoules)
11:28 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
11:28 < aureleoules> So I've been experimenting with mutation testing with brunoerg
11:29 < aureleoules> It's a testing technique that allows to discover parts of the code that is untested
11:29 < achow101> anything interesting?
11:29 < aureleoules> So far I've built this UI https://bcm-ui.aureleoules.com/status/NotKilled
11:29 < aureleoules> I believe it works well but it produces a lot of data
11:30 < brunoerg> Yeah
11:30 < aureleoules> Some mutations are just belt and suspenders check that are not reachable by the users
11:30 < achow101> are the mutations generated automatically or by hand?
11:30 < vasild> "discover parts of the code that is untested" -- is that not basic code coverage?
11:30 < _aj_> i like that the status/Killed link has the website die in sympathy :)
11:30 < aureleoules> They are generated automatically using regexes but the files are choosen manually for now
11:31 < aureleoules> vasild: it does sometime overlap with classical test coverage but it also discovers new parts of the code that is untested
11:31 < _aj_> vasild: code coverage just tells you that it was executed, not that the semantics were tested
11:31 < lightlike> is it unit tests only, or would it only find mutations killed by functional tests?
11:31 < aureleoules> you can match the results with https://marcofalke.github.io/btc_cov/total.coverage/index.html for example
11:31 < lightlike> *also find
11:31 < aureleoules> _aj_: haha yes I haven't done the pagination yet, netlify doesnt like it
11:32 < aureleoules> lightlike: I first run the unit tests because they are faster and then the functional tests, if none crash it means the mutation has survived and a test should be added
11:32 < _aj_> aureleoules: what does "Fixed" mean?
11:33 < brunoerg> reminding that it's not a generalist C++ tool, but focused on Bitcoin Core, because we have e.g. CAmount a = 1; and most tools can't deal with it
11:33 < aureleoules> _aj_: it means a test was added or ignored (for now) because it is unreachable code or not important to fix 
11:34 < aureleoules> you can mind some examples of mutations in this file for example: https://github.com/aureleoules/bticoin-core-mutuaitons/blob/master/mutator/src/mutators/std_algorithm.rs#L23
11:35 < achow101> it's definitely useful to have mutation testing. I think gmax was doing mutation testing for Taproot and found a couple of bugs that way. would be nice to have that over more prs
11:36 < aureleoules> the next step for me and bruno is to mutate the diff of pull requests to add as much test coverage and thus maybe find bugs
11:36 < vasild> Is that like replacing std::sort in the source code with std::stable_sort and checking if more code will be covered, compared to std::sort?
11:37 < aureleoules> i'm not sure what you mean by "if more code will be covered"
11:37 < aureleoules> but it tests that the CI should crash with std::stable_sort
11:37 < aureleoules> this may not be a very useful mutator after all
11:38 < aureleoules> std::min -> std::max is more likely to crash
11:38 < brunoerg> if it doesn't crash with stable_sort, it means we should use it instead? is this the purpose?
11:38 < vasild> I mean different code path to be executed
11:39 < _aj_> mutation testing is about introducing bugs into the code (by changing if (x == y) to if (x != y) and similar), and seeing if the existing tests catch the bug and report an error, or if all the tests pass
11:40 < vasild> ah, I see now, thanks _aj_!
11:41 < aureleoules> if it doesn't crash with stable_sort it means that there should be a test somewhere that checks how a vector was sorted (but I believe this is usually not tested)
11:41 < _aj_> int subtract(int a, int b) { return a + b; } // you can have a fuzz tester that has 100% coverage of that code, despite the obvious bug. mutation testing will tell you the tests don't care that you're return "a + b" or "a - b", which will definitely help improve the tests, and may make the bug obvious
11:41 < brunoerg> _aj_: perfect
11:42 < MacroFake> Does it parse the AST or will it also modify string literal contents?
11:42 < aureleoules> I doesn't parse the AST, it parses the source code with simple regexes (for now)
11:42 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
11:42 < aureleoules> And I added a check to not mutate string litterals
11:42 < aureleoules> the bottle neck is not the compile time it's the CI, so I don't think mutating the AST is the priority
11:43 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
11:43 < aureleoules> it* doesnt
11:44 < MacroFake> Does it use ccache?
11:44 < aureleoules> yes
11:45 < aureleoules> I can add as many workers to execute the mutations with a simple docker run 
11:45 < aureleoules> the Dockerfile for the worker is here https://github.com/aureleoules/bticoin-core-mutuaitons/blob/master/docker/Dockerfile.builder
11:45 < aureleoules> It contains a pre-compiled bitcoin-core with ccache (thus the image is heavy) but the first compilation is fast
11:45 < vasild> bticoin
11:46 < aureleoules> vasild: yes the repo name has been mutated as well :)
11:46 < vasild> :-D
11:46 < brunoerg> lol
11:47 < vasild> this sounds super cool!
11:48 < aureleoules> thanks!
11:49 < aureleoules> if you have an idea on how to make it better, issues are very welcome!
11:49 < achow101> awesome
11:49 < achow101> any other topics to discuss?
11:49 < vasild> what about deleting random lines of code and seeing what happens?
11:50 < aureleoules> vasild: I have thought of that but that will produce huge amounts of data
11:50 < aureleoules> considering every file is 4000 lines
11:50 < instagibbs> aureleoules, could "score" subroutines based on importance
11:50 < vasild> yeah, and 99% compilation failures, I guess
11:50 < brunoerg> i'm working on a CLI for asmap stuff, it downloads dumps, convert dump files to human-readable ones, compare two files, and other stuff. if anyone has any idea to improve it or features it could have, that's the repo: https://github.com/brunoerg/asmapy
11:50 -!- _Sam-- [~sam@52.152.220.68] has quit [Remote host closed the connection]
11:51 < instagibbs> i did some manual mutation testing for taproot as well, but i focused on things like sighashes and related, not the entire PR
11:51 < aureleoules> i could add a check to not mutate brackets
11:51 < instagibbs> (found a bug as well)
11:51 < aureleoules> but compile time failures are great because they happen quickly
11:52 < vasild> maybe just for the lines that are added or modified in open PRs, not for the entire code base
11:52 < aureleoules> instagibbs: what do you mean by "could "score" subroutines based on importance"
11:52 < aureleoules> vasild: yes this is planned
11:52 < instagibbs> files are big, but some functions are very small and very important
11:53 < instagibbs> triaging mutation testing coverage by consensus criticality 
11:53 < brunoerg> we could point what interval of lines we wanna mutate
11:53 < aureleoules> good idea brunoerg
11:56 < achow101> #endmeeting
11:56 <@core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
11:56 <@core-meetingbot> Meeting ended Thu Dec 15 19:56:09 2022 UTC.  
11:56 <@core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-12-15-19.03.moin.txt
12:23 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:41 < bitcoin-git> [bitcoin] hebasto opened pull request #26707: clang-tidy: Fix `performance-move-const-arg` in headers (master...221215-tidy-move) https://github.com/bitcoin/bitcoin/pull/26707
12:52 -!- kmartin [~kmartin@20014C4E24D79A007B45CAFA8A79EA4A.dsl.pool.telekom.hu] has quit [Ping timeout: 260 seconds]
13:08 < bitcoin-git> [bitcoin] hebasto opened pull request #26708: clang-tidy: Fix `modernize-use-nullptr` in headers (master...221215-tidy-null) https://github.com/bitcoin/bitcoin/pull/26708
13:30 < ariard> sdaftuar: re-ACP on LN time-sensitive txn, post-anchor yes we have a subset signed under single|acp; however the spent utxo can only be spent by one party until timelock expiration
13:30 < ariard> if you're consuming fee-bumping inputs from a third-party ancestor, you might have pinnings issues
13:36 < bitcoin-git> [gui] hebasto opened pull request #685: clang-tidy: Fix `readability-redundant-string-init` in headers (master...221215-tidy-string) https://github.com/bitcoin-core/gui/pull/685
13:46 < sdaftuar> i don't quite follow everything you said, but i assume its a problem if the time-sensitive transaction doesn't confirm? if so i think any random 3rd party would be able to do that just by knocking it out of the mempool whenever it shows up on the network
14:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c9ac:9d5c:7309:a398] has quit []
14:08 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.7.1]
14:15 < instagibbs> two sets of signatures in that case i think
14:15 < instagibbs> presigned signatures SINGLE|ACP, then another ALL when attaching fees that only the owner can use
14:15 < instagibbs> https://github.com/lightning/bolts/blob/master/05-onchain.md#generation-of-htlc-transactions
14:38 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:9f97:ce49:553a:6cb3] has joined #bitcoin-core-dev
14:40 -!- Guest17 [~Guest17@2601:805:8500:2680:1d4a:e18c:5cc0:1e02] has joined #bitcoin-core-dev
14:40 -!- sipsorcery2 [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
14:44 -!- Guest17 [~Guest17@2601:805:8500:2680:1d4a:e18c:5cc0:1e02] has quit [Client Quit]
14:48 -!- sipsorcery2 [~sipsorcer@2a02:8084:6180:500::12b] has quit [Quit: Leaving]
15:04 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:9f97:ce49:553a:6cb3] has quit [Read error: Connection reset by peer]
15:07 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
15:08 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has joined #bitcoin-core-dev
15:08 -!- sipsorcery_ [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has joined #bitcoin-core-dev
15:09 -!- sipsorcery_ [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has quit [Client Quit]
15:14 < sdaftuar> got it -- so i think that's easily attackable, right? knock the transaction out once a higher feerate transaction that includes the same SINGLE|ACP input, and knock that input out altogether with another replacement that conflicts a different input
15:14 < sdaftuar> once with* a higher feerate
15:25 < ariard> ah i think i see what you're describing -- you would have a single|acp HTLC-timeout, this "honest" transaction is 1) replaced by a higher feerate HTLC-timeout' spending a replaceable parent and then 2) the parent is knocked out?
15:26 < ariard> though in this case, the script path is only spendable by Alice until the HTLC absolute timelock expires, at expiration effectively Bob could win the race in this unfair fashion
15:27 < ariard> yes this is a fund loss problem if a LN time-sensitive transaction doesn't confirm...especially if it can be triggered at low-cost by exploiting mempools rules
15:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
15:30 < sdaftuar> ariard: that's one way to do it, but you don't even need to involve any transaction chains for the simple attack i'm describing. if txA is the honest transaction that has a SINGLE|ACP input, then construct txB that conflicts with A by including that SINGLE|ACP input as well as one other input, and then contruct txC that conflicts with the second input of txB which drops the SINGLE|ACP
15:30 < sdaftuar> input.
15:31 < sdaftuar> if you wanted to take this a step further and save money as an attacker, then yes you could use transaction chains to be able to do these RBFs more cheaply as well, i think
15:32 < sdaftuar> but i'm assuming that even if an attacker is willing to pay the prevailing feerate once per block, that this would be a situation you would want to avoid
15:35 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
15:36 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
15:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
15:48 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has quit [Ping timeout: 252 seconds]
16:06 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has joined #bitcoin-core-dev
16:13 -!- gnaf [~gnaf@93-190-140-117.hosted-by-worldstream.net] has quit [Ping timeout: 252 seconds]
16:40 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has quit [Ping timeout: 252 seconds]
17:16 < ariard> yes you could construct txC has conflicting with multiple inputs from unrelated chain of transactions, that way gaining a batching effect as an adversary
17:30 -!- sdhsdsj [~sdhsdsj@163.116.192.118] has joined #bitcoin-core-dev
19:12 -!- tun4 [~tun4@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
20:01 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
20:03 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
20:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
20:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
20:08 -!- tun4 [~tun4@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com] has quit [Quit: Client closed]
20:13 -!- jonatack2 [~jonatack@user/jonatack] has joined #bitcoin-core-dev
20:14 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
20:20 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
20:32 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
20:51 -!- sdhsdsj [~sdhsdsj@163.116.192.118] has quit [Quit: Client closed]
20:52 -!- sdhsdsj [~sdhsdsj@163.116.192.118] has joined #bitcoin-core-dev
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:14 -!- sdhsdsj [~sdhsdsj@163.116.192.118] has quit [Quit: Client closed]
22:01 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
22:04 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
22:04 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has quit [Quit: 404]
22:34 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
22:37 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
22:46 -!- bitdex_ [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
22:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 255 seconds]
23:55 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
23:56 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
23:57 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
--- Log closed Fri Dec 16 00:00:47 2022