12022-12-15T00:20:23 <bitcoin-git> [bitcoin] theStack opened pull request #26702: walletdb: refactor: drop unused `FindWalletTx` parameter and rename (master...202212-walletdb-refactor_simplify_findwallettx) https://github.com/bitcoin/bitcoin/pull/26702
22022-12-15T00:29:09 *** jrawsthorne <jrawsthorne!~jrawsthor@static.235.41.217.95.clients.your-server.de> has quit IRC (Quit: ZNC 1.8.1 - https://znc.in)
32022-12-15T00:46:35 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
42022-12-15T00:59:11 *** BUSY <BUSY!~BUSY@user/busy> has quit IRC (Remote host closed the connection)
52022-12-15T01:02:18 *** BUSY <BUSY!~BUSY@user/busy> has joined #bitcoin-core-dev
62022-12-15T01:03:47 *** enyc <enyc!~enyc@user/enyc> has quit IRC (Ping timeout: 264 seconds)
72022-12-15T01:10:22 *** enyc <enyc!~enyc@user/enyc> has joined #bitcoin-core-dev
82022-12-15T01:13:32 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500::12b> has quit IRC (Ping timeout: 252 seconds)
92022-12-15T01:24:33 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has quit IRC (Quit: as2333)
102022-12-15T01:24:58 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has joined #bitcoin-core-dev
112022-12-15T02:32:02 *** hardy <hardy!~H@200.24.13.246> has quit IRC (Remote host closed the connection)
122022-12-15T02:38:15 *** ___nick___ <___nick___!~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
132022-12-15T02:39:22 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has quit IRC (Quit: as2333)
142022-12-15T02:39:44 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has joined #bitcoin-core-dev
152022-12-15T02:39:59 *** ___nick___ <___nick___!~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net> has joined #bitcoin-core-dev
162022-12-15T02:40:49 *** ___nick___ <___nick___!~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net> has quit IRC (Client Quit)
172022-12-15T02:42:43 *** ___nick___ <___nick___!~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net> has joined #bitcoin-core-dev
182022-12-15T02:51:00 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has quit IRC (Quit: as2333)
192022-12-15T03:45:29 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
202022-12-15T03:46:28 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
212022-12-15T04:02:44 *** Takemitchy <Takemitchy!~Takemitch@2604:3d09:677:5a00:9d79:a4da:8cfa:5a37> has joined #bitcoin-core-dev
222022-12-15T04:04:17 *** Takemitchy <Takemitchy!~Takemitch@2604:3d09:677:5a00:9d79:a4da:8cfa:5a37> has quit IRC (Client Quit)
232022-12-15T04:25:59 *** b_101_ <b_101_!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 246 seconds)
242022-12-15T05:01:02 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
252022-12-15T05:01:32 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
262022-12-15T05:31:44 *** Guest3751 <Guest3751!~Guest37@2409:4043:2388:4f04:a5ce:cd3d:f3f2:e10b> has joined #bitcoin-core-dev
272022-12-15T05:33:24 *** Guest3751 <Guest3751!~Guest37@2409:4043:2388:4f04:a5ce:cd3d:f3f2:e10b> has quit IRC (Client Quit)
282022-12-15T05:41:36 *** kdmukai <kdmukai!~kdmukai@104-0-42-7.lightspeed.cicril.sbcglobal.net> has joined #bitcoin-core-dev
292022-12-15T06:02:24 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
302022-12-15T06:07:48 *** sudoforge <sudoforge!~sudoforge@wireguard/tunneler/sudoforge> has quit IRC (Ping timeout: 272 seconds)
312022-12-15T06:07:58 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 252 seconds)
322022-12-15T06:14:30 *** kdmukai <kdmukai!~kdmukai@104-0-42-7.lightspeed.cicril.sbcglobal.net> has quit IRC (Quit: Client closed)
332022-12-15T06:23:00 *** ___nick___ <___nick___!~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net> has quit IRC (Ping timeout: 272 seconds)
342022-12-15T07:28:16 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #19262: rpc: Replace OMITTED_NAMED_ARG with OMITTED (master...2006-rpcHelpRefactor) https://github.com/bitcoin/bitcoin/pull/19262
352022-12-15T08:10:36 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
362022-12-15T08:10:48 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
372022-12-15T08:21:59 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
382022-12-15T08:23:45 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
392022-12-15T08:26:44 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
402022-12-15T08:42:12 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500::12b> has joined #bitcoin-core-dev
412022-12-15T09:22:49 *** demono <demono!~demono@77.109.165.235> has joined #bitcoin-core-dev
422022-12-15T09:25:36 *** sgiath <sgiath!~sgiath@mail.sgiath.dev> has quit IRC (Ping timeout: 255 seconds)
432022-12-15T09:25:55 *** sgiath <sgiath!~sgiath@2a02:25b0:aaaa:aaaa:a3c3:ed4b:6b06:0> has joined #bitcoin-core-dev
442022-12-15T09:29:34 *** demono <demono!~demono@77.109.165.235> has quit IRC (Quit: Client closed)
452022-12-15T10:27:34 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
462022-12-15T10:27:43 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
472022-12-15T10:43:49 <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
482022-12-15T11:00:10 *** bomb-on <bomb-on!~bomb-on@user/bomb-on> has joined #bitcoin-core-dev
492022-12-15T11:31:27 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:c9ac:9d5c:7309:a398> has joined #bitcoin-core-dev
502022-12-15T11:39:31 *** infernix <infernix!nix@spirit.infernix.net> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
512022-12-15T12:10:48 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ba47a4ba97e9...9a72119e7e27
522022-12-15T12:10:48 <bitcoin-git> bitcoin/master fa34e5f MarcoFalke: test: Avoid intermittent timeout in feature_assumevalid.py
532022-12-15T12:10:49 <bitcoin-git> bitcoin/master 9a72119 MarcoFalke: Merge bitcoin/bitcoin#26651: test: Avoid intermittent timeout in feature_a...
542022-12-15T12:10:56 <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
552022-12-15T12:19:47 *** infernix <infernix!nix@spirit.infernix.net> has joined #bitcoin-core-dev
562022-12-15T12:36:09 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9a72119e7e27...03708dac0ac6
572022-12-15T12:36:10 <bitcoin-git> bitcoin/master 062e4e9 fanquake: doc: add 22.1 release notes
582022-12-15T12:36:10 <bitcoin-git> bitcoin/master 03708da MarcoFalke: Merge bitcoin/bitcoin#26704: doc: add 22.1 release notes
592022-12-15T12:36:12 <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
602022-12-15T12:50:31 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Remote host closed the connection)
612022-12-15T12:54:20 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
622022-12-15T13:05:04 *** vasild <vasild!~vd@user/vasild> has quit IRC (Quit: leaving)
632022-12-15T13:36:10 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
642022-12-15T13:48:54 *** Hercules1 <Hercules1!~Hercules@ti0018a400-7782.bb.online.no> has joined #bitcoin-core-dev
652022-12-15T13:52:44 *** Hercules1 <Hercules1!~Hercules@ti0018a400-7782.bb.online.no> has quit IRC (Quit: Leaving)
662022-12-15T13:59:22 *** jtraub91 <jtraub91!~jason@c-76-111-232-173.hsd1.fl.comcast.net> has joined #bitcoin-core-dev
672022-12-15T14:08:47 *** x22x22x <x22x22x!~x88x88x@2001:19f0:5:39a8:5400:3ff:feb6:73cb> has quit IRC (Ping timeout: 252 seconds)
682022-12-15T14:10:26 <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
692022-12-15T14:10:28 <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
702022-12-15T14:13:50 <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.
712022-12-15T14:14:37 <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.
722022-12-15T14:14:57 <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
732022-12-15T14:16:32 *** freesprung <freesprung!~freesprun@user/freesprung> has quit IRC (Ping timeout: 256 seconds)
742022-12-15T14:18:16 <darosior> (for rule2 it's not really pinning per se, i don't know how we could name it)
752022-12-15T14:23:09 <sdaftuar> i guess conceptually what i described is no different from rule #3 pinning, in terms of economic effect
762022-12-15T14:23:11 <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
772022-12-15T14:27:22 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
782022-12-15T14:28:15 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
792022-12-15T14:32:23 <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
802022-12-15T14:33:15 <darosior> instagibbs: but if you sign with SINGLE|ACP a third party can always add some whether you need them or not
812022-12-15T14:33:33 <instagibbs> *they* can pin themself via rule 2... sure
822022-12-15T14:34:58 <instagibbs> honest party just won't source unconfirmed inputs, in this scenario at least
832022-12-15T14:35:28 <instagibbs> (does not generalize I know)
842022-12-15T14:35:34 <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.
852022-12-15T14:36:00 <instagibbs> that's on the same order as rule 3 pin, no?
862022-12-15T14:36:12 <instagibbs> nothing to do with rule 2
872022-12-15T14:36:34 <instagibbs> s/rule 3/economic pin/ maybe
882022-12-15T14:37:00 <instagibbs> I don't think we're disagreeing :)
892022-12-15T14:37:22 *** freesprung <freesprung!~freesprun@user/freesprung> has joined #bitcoin-core-dev
902022-12-15T14:40:52 <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
912022-12-15T14:41:54 <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.
922022-12-15T14:43:01 <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
932022-12-15T14:43:19 <sdaftuar> glozow:good point on the scaling effect!
942022-12-15T14:43:28 <instagibbs> oh, these are bizarre uses lol
952022-12-15T14:43:46 <instagibbs> yeah very interesting point glozow
962022-12-15T14:46:42 <instagibbs> sdaftuar, in general I'm assuming people aren't doing batching, or if they are, they don't care about confirmation speed....
972022-12-15T14:57:46 *** sudoforge <sudoforge!~sudoforge@wireguard/tunneler/sudoforge> has joined #bitcoin-core-dev
982022-12-15T14:59:28 *** b10c <b10c!~quassel@user/b10c> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
992022-12-15T15:01:19 *** b10c <b10c!~quassel@static.33.106.217.95.clients.your-server.de> has joined #bitcoin-core-dev
1002022-12-15T15:10:24 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
1012022-12-15T15:15:11 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 264 seconds)
1022022-12-15T15:17:01 <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
1032022-12-15T15:17:19 <jamesob> but I think fundamentally, all of this boils down to rule #3-style griefing, _not_ strict pinning
1042022-12-15T15:17:21 <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
1052022-12-15T15:21:05 <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
1062022-12-15T15:22:49 <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)
1072022-12-15T15:23:08 <instagibbs> I mean, it also is worked around by being "first"
1082022-12-15T15:24:30 <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?
1092022-12-15T15:25:07 <instagibbs> given today's policy(no package CPFP_, likely
1102022-12-15T15:25:14 <jamesob> instagibbs: right, but you can't ever really rely on being "first" given mempool mapping/frontrunning
1112022-12-15T15:25:28 <instagibbs> it's a incentive compat vs pinning tension I guess
1122022-12-15T15:26:09 <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
1132022-12-15T15:28:09 <instagibbs> it's essentially a pinning multiplier on top of rule3 pin, if you're batching these state updates
1142022-12-15T15:28:48 <instagibbs> state update == the inputs and updates that cannot be separated due to sighash coverage... need a better term for this
1152022-12-15T15:33:44 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500::12b> has quit IRC (Ping timeout: 252 seconds)
1162022-12-15T15:33:44 *** _Sam-- <_Sam--!~sam@52.152.220.68> has joined #bitcoin-core-dev
1172022-12-15T15:34:00 <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
1182022-12-15T15:35:31 <instagibbs> ok sdaftuar's point is that if your adversary can BYOF more compactly than you, it increases the pin
1192022-12-15T15:35:47 <instagibbs> corollary is that if your attacker doesn't have chunky utxos they can't pin as much
1202022-12-15T15:36:54 <sdaftuar> instagibbs: ah but in this particular case, the attacker can construct a "chunky" utxo with the large unconfirmed ancestor
1212022-12-15T15:37:24 <sdaftuar> at least potnetially
1222022-12-15T15:37:48 <instagibbs> that's fine, I'm assuming we're maxing out package size here
1232022-12-15T15:38:36 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
1242022-12-15T15:39:08 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev
1252022-12-15T15:41:44 <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?
1262022-12-15T15:42:14 <jamesob> (where reformulated = packed into a new transaction by griefer)
1272022-12-15T15:44:46 <glozow> jamesob: yep. acp + rbf = anyone can bump you down
1282022-12-15T15:44:49 <instagibbs> so I think the key is this additional pinning multiplier only exists with ancestral junk (just clear to me now)
1292022-12-15T15:45:39 <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
1302022-12-15T15:46:12 <sdaftuar> naively: you send a transaction, i conflict it, and then i conflict that version in a way that drops your input.
1312022-12-15T15:46:34 <sdaftuar> if you are paying attention you can rebroadcast, but i think it might not relay due to bandwidth optimizations
1322022-12-15T15:46:38 <sdaftuar> (for a while)
1332022-12-15T15:47:01 <sdaftuar> or you can broadcast an alternate version of your transaction, and the adversary can play the same game
1342022-12-15T15:47:18 <sdaftuar> morally speaking it should be expensive for the attacker to do this, but it may not be:
1352022-12-15T15:48:13 <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.
1362022-12-15T15:49:12 <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)
1372022-12-15T15:52:49 *** test__ is now known as _flood
1382022-12-15T15:58:41 *** hg <hg!~halosghos@user/halosghost> has joined #bitcoin-core-dev
1392022-12-15T15:59:32 <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
1402022-12-15T16:07:40 <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
1412022-12-15T16:10:13 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500::12b> has joined #bitcoin-core-dev
1422022-12-15T16:18:46 *** kexkey <kexkey!~kexkey@static-198-54-132-132.cust.tzulo.com> has joined #bitcoin-core-dev
1432022-12-15T16:21:26 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Write error: Connection reset by peer)
1442022-12-15T16:21:54 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
1452022-12-15T16:37:58 *** kexkey <kexkey!~kexkey@static-198-54-132-132.cust.tzulo.com> has quit IRC (Ping timeout: 272 seconds)
1462022-12-15T16:38:51 *** kexkey <kexkey!~kexkey@static-198-54-132-140.cust.tzulo.com> has joined #bitcoin-core-dev
1472022-12-15T16:43:20 *** gnaf <gnaf!~gnaf@93-190-140-117.hosted-by-worldstream.net> has joined #bitcoin-core-dev
1482022-12-15T16:48:16 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Quit: Leaving)
1492022-12-15T16:49:21 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
1502022-12-15T16:49:27 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Read error: Connection reset by peer)
1512022-12-15T16:50:20 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
1522022-12-15T16:51:57 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
1532022-12-15T16:52:23 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
1542022-12-15T16:54:12 <bitcoin-git> [bitcoin] dhruv closed pull request #24545: BIP324: Enable v2 P2P encrypted transport (master...bip324-enable) https://github.com/bitcoin/bitcoin/pull/24545
1552022-12-15T16:55:53 <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?
1562022-12-15T16:55:55 <gribble> https://github.com/bitcoin/bitcoin/issues/24545 | BIP324: Enable v2 P2P encrypted transport by dhruv · Pull Request #24545 · bitcoin/bitcoin · GitHub
1572022-12-15T16:56:48 <fanquake> not after you've deleted the branch
1582022-12-15T16:56:56 <dhruv> So I need to make a new PR?
1592022-12-15T16:57:11 <fanquake> Can you restore the branch
1602022-12-15T16:57:54 <dhruv> I did push it back up with the same branch name
1612022-12-15T16:58:16 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
1622022-12-15T16:58:17 <dhruv> Is that what you mean by restore?
1632022-12-15T16:58:55 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
1642022-12-15T16:59:26 <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.
1652022-12-15T17:00:15 <_aj_> yeah, force push back to 8f7714e33804b6cf96fedbe05751d1a700e1e8d1, reopen, then force push again
1662022-12-15T17:00:29 <dhruv> ah, ok let me try that.
1672022-12-15T17:02:42 <bitcoin-git> [bitcoin] dhruv reopened pull request #24545: BIP324: Enable v2 P2P encrypted transport (master...bip324-enable) https://github.com/bitcoin/bitcoin/pull/24545
1682022-12-15T17:02:52 <dhruv> that worked. Thank you fanquake and _aj_!
1692022-12-15T17:15:18 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500::12b> has quit IRC (Ping timeout: 252 seconds)
1702022-12-15T17:30:16 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
1712022-12-15T17:46:47 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
1722022-12-15T17:47:26 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
1732022-12-15T17:49:30 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
1742022-12-15T17:56:09 *** jtraub91_ <jtraub91_!~jason@2607:fb91:1905:a397:dd76:2a3b:8fbc:f7db> has joined #bitcoin-core-dev
1752022-12-15T17:56:59 <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
1762022-12-15T17:57:35 <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
1772022-12-15T17:57:40 <sdaftuar> er upper bound
1782022-12-15T17:59:02 *** jtraub91 <jtraub91!~jason@c-76-111-232-173.hsd1.fl.comcast.net> has quit IRC (Ping timeout: 272 seconds)
1792022-12-15T18:00:47 *** jtraub91_ <jtraub91_!~jason@2607:fb91:1905:a397:dd76:2a3b:8fbc:f7db> has quit IRC (Ping timeout: 246 seconds)
1802022-12-15T18:02:16 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
1812022-12-15T18:09:22 *** b_101_ <b_101_!~robert@189.236.6.68> has joined #bitcoin-core-dev
1822022-12-15T18:10:01 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
1832022-12-15T18:10:37 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
1842022-12-15T18:11:46 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 252 seconds)
1852022-12-15T18:12:57 <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)
1862022-12-15T18:13:33 <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)
1872022-12-15T18:23:07 *** sudoforge <sudoforge!~sudoforge@wireguard/tunneler/sudoforge> has quit IRC (Quit: 404)
1882022-12-15T18:24:47 *** sudoforge <sudoforge!~sudoforge@wireguard/tunneler/sudoforge> has joined #bitcoin-core-dev
1892022-12-15T18:37:22 <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
1902022-12-15T18:39:12 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
1912022-12-15T18:41:33 *** b_101_ <b_101_!~robert@189.236.6.68> has quit IRC (Ping timeout: 268 seconds)
1922022-12-15T19:01:19 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
1932022-12-15T19:01:41 <achow101> meeting?
1942022-12-15T19:01:45 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
1952022-12-15T19:01:58 *** kmartin <kmartin!~kmartin@20014C4E24D79A007B45CAFA8A79EA4A.dsl.pool.telekom.hu> has joined #bitcoin-core-dev
1962022-12-15T19:03:31 <achow101> Guess I can run it
1972022-12-15T19:03:37 <achow101> #startmeeting
1982022-12-15T19:03:37 <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.
1992022-12-15T19:03:37 <core-meetingbot> Available commands: action commands idea info link nick
2002022-12-15T19:03:44 <brunoerg> hi
2012022-12-15T19:04:06 <lightlike> hi
2022022-12-15T19:04:09 <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
2032022-12-15T19:04:09 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
2042022-12-15T19:04:24 <vasild> hi
2052022-12-15T19:04:24 <kanzure> hi
2062022-12-15T19:04:34 <achow101> Welcome to the weekly general IRC meeting
2072022-12-15T19:05:03 <LarryRuane> Hi
2082022-12-15T19:05:18 <achow101> There is one preproposed meeting topic: https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
2092022-12-15T19:05:38 <achow101> any last minute topics to add?
2102022-12-15T19:06:19 <achow101> Let's start with the usual
2112022-12-15T19:06:25 <achow101> #topic High priority for review
2122022-12-15T19:06:25 <core-meetingbot> topic: High priority for review
2132022-12-15T19:06:53 <achow101> https://github.com/orgs/bitcoin/projects/1 anything to add/merge/remove?
2142022-12-15T19:07:19 <Murch1> Hi
2152022-12-15T19:08:05 <achow101> and also reminder that we now have https://github.com/orgs/bitcoin/projects/5 where people can add their own PRs
2162022-12-15T19:08:52 <brunoerg> cool
2172022-12-15T19:08:57 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has joined #bitcoin-core-dev
2182022-12-15T19:10:19 <achow101> #topic https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
2192022-12-15T19:10:19 <core-meetingbot> topic: https://github.com/bitcoin/bitcoin/pull/25871 (bytes1440000)
2202022-12-15T19:10:27 <achow101> #25871
2212022-12-15T19:10:29 <gribble> https://github.com/bitcoin/bitcoin/issues/25871 | contrib: add vasild to trusted keys by vasild · Pull Request #25871 · bitcoin/bitcoin · GitHub
2222022-12-15T19:11:07 <vasild> I have no idea what is the status of that, but I am here to answer questions, if any (a bit sleepy, though :)
2232022-12-15T19:11:10 <achow101> I think bytes1440000 was wondering what the status of that was
2242022-12-15T19:11:19 <b10c> hi
2252022-12-15T19:13:19 <achow101> I think the current status is that a few contributors are -0 or -1
2262022-12-15T19:16:18 <achow101> and the next steps would be to follow up with those contributors to see if any of the discussion has changed their opinion
2272022-12-15T19:16:54 <aureleoules> hi
2282022-12-15T19:17:36 <achow101> anything else to discuss?
2292022-12-15T19:18:26 <aureleoules> yes
2302022-12-15T19:18:44 <aureleoules> I've been experimenting with brunoerg on mutation testing and I would love your feedback
2312022-12-15T19:18:53 <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...
2322022-12-15T19:19:18 <vasild> no -0 either
2332022-12-15T19:19:34 <achow101> vasild: dergoegge fanquake and jeremyrubin I think
2342022-12-15T19:20:08 <achow101> unless I missed a followup comment, but no acks from them either
2352022-12-15T19:21:17 <_aj_> are there any PRs that are stalling due to lack of people merging, rather than lack of review or waiting-for-author/rebase?
2362022-12-15T19:22:03 <_aj_> (if so, maybe move them to the Ready for merge column in the "PR Statuses" project linked above?)
2372022-12-15T19:23:26 <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
2382022-12-15T19:24:10 <achow101> although some may have had acks until they got conflicted and needed rebasing
2392022-12-15T19:26:22 <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
2402022-12-15T19:26:30 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
2412022-12-15T19:27:00 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2422022-12-15T19:28:02 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Client Quit)
2432022-12-15T19:28:05 <achow101> doesn't seem like there's much else to say on this topic
2442022-12-15T19:28:14 <achow101> #topic mutation testing (aureleoules)
2452022-12-15T19:28:15 <core-meetingbot> topic: mutation testing (aureleoules)
2462022-12-15T19:28:48 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2472022-12-15T19:28:52 <aureleoules> So I've been experimenting with mutation testing with brunoerg
2482022-12-15T19:29:04 <aureleoules> It's a testing technique that allows to discover parts of the code that is untested
2492022-12-15T19:29:13 <achow101> anything interesting?
2502022-12-15T19:29:25 <aureleoules> So far I've built this UI https://bcm-ui.aureleoules.com/status/NotKilled
2512022-12-15T19:29:54 <aureleoules> I believe it works well but it produces a lot of data
2522022-12-15T19:30:11 <brunoerg> Yeah
2532022-12-15T19:30:18 <aureleoules> Some mutations are just belt and suspenders check that are not reachable by the users
2542022-12-15T19:30:28 <achow101> are the mutations generated automatically or by hand?
2552022-12-15T19:30:33 <vasild> "discover parts of the code that is untested" -- is that not basic code coverage?
2562022-12-15T19:30:36 <_aj_> i like that the status/Killed link has the website die in sympathy :)
2572022-12-15T19:30:47 <aureleoules> They are generated automatically using regexes but the files are choosen manually for now
2582022-12-15T19:31:14 <aureleoules> vasild: it does sometime overlap with classical test coverage but it also discovers new parts of the code that is untested
2592022-12-15T19:31:18 <_aj_> vasild: code coverage just tells you that it was executed, not that the semantics were tested
2602022-12-15T19:31:30 <lightlike> is it unit tests only, or would it only find mutations killed by functional tests?
2612022-12-15T19:31:32 <aureleoules> you can match the results with https://marcofalke.github.io/btc_cov/total.coverage/index.html for example
2622022-12-15T19:31:41 <lightlike> *also find
2632022-12-15T19:31:53 <aureleoules> _aj_: haha yes I haven't done the pagination yet, netlify doesnt like it
2642022-12-15T19:32:21 <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
2652022-12-15T19:32:29 <_aj_> aureleoules: what does "Fixed" mean?
2662022-12-15T19:33:04 <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
2672022-12-15T19:33:06 <aureleoules> _aj_: it means a test was added or ignored (for now) because it is unreachable code or not important to fix
2682022-12-15T19:34:23 <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
2692022-12-15T19:35:11 <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
2702022-12-15T19:36:15 <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
2712022-12-15T19:36: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?
2722022-12-15T19:37:32 <aureleoules> i'm not sure what you mean by "if more code will be covered"
2732022-12-15T19:37:42 <aureleoules> but it tests that the CI should crash with std::stable_sort
2742022-12-15T19:37:55 <aureleoules> this may not be a very useful mutator after all
2752022-12-15T19:38:11 <aureleoules> std::min -> std::max is more likely to crash
2762022-12-15T19:38:28 <brunoerg> if it doesn't crash with stable_sort, it means we should use it instead? is this the purpose?
2772022-12-15T19:38:32 <vasild> I mean different code path to be executed
2782022-12-15T19:39:46 <_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
2792022-12-15T19:40:15 <vasild> ah, I see now, thanks _aj_!
2802022-12-15T19:41:12 <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)
2812022-12-15T19:41:27 <_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
2822022-12-15T19:41:44 <brunoerg> _aj_: perfect
2832022-12-15T19:42:00 <MacroFake> Does it parse the AST or will it also modify string literal contents?
2842022-12-15T19:42:23 <aureleoules> I doesn't parse the AST, it parses the source code with simple regexes (for now)
2852022-12-15T19:42:24 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Remote host closed the connection)
2862022-12-15T19:42:33 <aureleoules> And I added a check to not mutate string litterals
2872022-12-15T19:42:52 <aureleoules> the bottle neck is not the compile time it's the CI, so I don't think mutating the AST is the priority
2882022-12-15T19:43:11 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2892022-12-15T19:43:11 <aureleoules> it* doesnt
2902022-12-15T19:44:16 <MacroFake> Does it use ccache?
2912022-12-15T19:44:23 <aureleoules> yes
2922022-12-15T19:45:17 <aureleoules> I can add as many workers to execute the mutations with a simple docker run
2932022-12-15T19:45:23 <aureleoules> the Dockerfile for the worker is here https://github.com/aureleoules/bticoin-core-mutuaitons/blob/master/docker/Dockerfile.builder
2942022-12-15T19:45:58 <aureleoules> It contains a pre-compiled bitcoin-core with ccache (thus the image is heavy) but the first compilation is fast
2952022-12-15T19:45:58 <vasild> bticoin
2962022-12-15T19:46:36 <aureleoules> vasild: yes the repo name has been mutated as well :)
2972022-12-15T19:46:52 <vasild> :-D
2982022-12-15T19:46:56 <brunoerg> lol
2992022-12-15T19:47:53 <vasild> this sounds super cool!
3002022-12-15T19:48:29 <aureleoules> thanks!
3012022-12-15T19:49:01 <aureleoules> if you have an idea on how to make it better, issues are very welcome!
3022022-12-15T19:49:33 <achow101> awesome
3032022-12-15T19:49:36 <achow101> any other topics to discuss?
3042022-12-15T19:49:47 <vasild> what about deleting random lines of code and seeing what happens?
3052022-12-15T19:50:14 <aureleoules> vasild: I have thought of that but that will produce huge amounts of data
3062022-12-15T19:50:24 <aureleoules> considering every file is 4000 lines
3072022-12-15T19:50:35 <instagibbs> aureleoules, could "score" subroutines based on importance
3082022-12-15T19:50:36 <vasild> yeah, and 99% compilation failures, I guess
3092022-12-15T19:50:47 <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
3102022-12-15T19:50:48 *** _Sam-- <_Sam--!~sam@52.152.220.68> has quit IRC (Remote host closed the connection)
3112022-12-15T19:51:00 <instagibbs> i did some manual mutation testing for taproot as well, but i focused on things like sighashes and related, not the entire PR
3122022-12-15T19:51:04 <aureleoules> i could add a check to not mutate brackets
3132022-12-15T19:51:08 <instagibbs> (found a bug as well)
3142022-12-15T19:51:20 <aureleoules> but compile time failures are great because they happen quickly
3152022-12-15T19:52:08 <vasild> maybe just for the lines that are added or modified in open PRs, not for the entire code base
3162022-12-15T19:52:19 <aureleoules> instagibbs: what do you mean by "could "score" subroutines based on importance"
3172022-12-15T19:52:34 <aureleoules> vasild: yes this is planned
3182022-12-15T19:52:43 <instagibbs> files are big, but some functions are very small and very important
3192022-12-15T19:53:01 <instagibbs> triaging mutation testing coverage by consensus criticality
3202022-12-15T19:53:10 <brunoerg> we could point what interval of lines we wanna mutate
3212022-12-15T19:53:49 <aureleoules> good idea brunoerg
3222022-12-15T19:56:09 <achow101> #endmeeting
3232022-12-15T19:56:09 <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
3242022-12-15T19:56:09 <core-meetingbot> Meeting ended Thu Dec 15 19:56:09 2022 UTC.
3252022-12-15T19:56:09 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-12-15-19.03.moin.txt
3262022-12-15T20:23:11 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
3272022-12-15T20:41:54 <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
3282022-12-15T20:52:08 *** kmartin <kmartin!~kmartin@20014C4E24D79A007B45CAFA8A79EA4A.dsl.pool.telekom.hu> has quit IRC (Ping timeout: 260 seconds)
3292022-12-15T21:08:59 <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
3302022-12-15T21:30:09 <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
3312022-12-15T21:30:41 <ariard> if you're consuming fee-bumping inputs from a third-party ancestor, you might have pinnings issues
3322022-12-15T21:36:44 <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
3332022-12-15T21:46:28 <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
3342022-12-15T22:01:39 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:c9ac:9d5c:7309:a398> has quit IRC ()
3352022-12-15T22:08:23 *** hg <hg!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 3.7.1)
3362022-12-15T22:15:21 <instagibbs> two sets of signatures in that case i think
3372022-12-15T22:15:52 <instagibbs> presigned signatures SINGLE|ACP, then another ALL when attaching fees that only the owner can use
3382022-12-15T22:15:53 <instagibbs> https://github.com/lightning/bolts/blob/master/05-onchain.md#generation-of-htlc-transactions
3392022-12-15T22:38:49 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:9f97:ce49:553a:6cb3> has joined #bitcoin-core-dev
3402022-12-15T22:40:33 *** Guest17 <Guest17!~Guest17@2601:805:8500:2680:1d4a:e18c:5cc0:1e02> has joined #bitcoin-core-dev
3412022-12-15T22:40:43 *** sipsorcery2 <sipsorcery2!~sipsorcer@2a02:8084:6180:500::12b> has joined #bitcoin-core-dev
3422022-12-15T22:44:35 *** Guest17 <Guest17!~Guest17@2601:805:8500:2680:1d4a:e18c:5cc0:1e02> has quit IRC (Client Quit)
3432022-12-15T22:48:53 *** sipsorcery2 <sipsorcery2!~sipsorcer@2a02:8084:6180:500::12b> has quit IRC (Quit: Leaving)
3442022-12-15T23:04:28 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:9f97:ce49:553a:6cb3> has quit IRC (Read error: Connection reset by peer)
3452022-12-15T23:07:50 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Ping timeout: 255 seconds)
3462022-12-15T23:08:38 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has joined #bitcoin-core-dev
3472022-12-15T23:08:48 *** sipsorcery_ <sipsorcery_!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has joined #bitcoin-core-dev
3482022-12-15T23:09:10 *** sipsorcery_ <sipsorcery_!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has quit IRC (Client Quit)
3492022-12-15T23:14:41 <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
3502022-12-15T23:14:53 <sdaftuar> once with* a higher feerate
3512022-12-15T23:25:42 <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?
3522022-12-15T23:26:36 <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
3532022-12-15T23:27:21 <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
3542022-12-15T23:30:19 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
3552022-12-15T23:30:55 <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
3562022-12-15T23:30:56 <sdaftuar> input.
3572022-12-15T23:31:27 <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
3582022-12-15T23:32:12 <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
3592022-12-15T23:35:15 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
3602022-12-15T23:36:20 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
3612022-12-15T23:44:26 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
3622022-12-15T23:48:22 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has quit IRC (Ping timeout: 252 seconds)