--- Log opened Wed Aug 31 00:00:06 2022
00:35 -!- Macx [uid89142@id-89142.lymington.irccloud.com] has joined #bitcoin-core-pr-reviews
00:38 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:38 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Write error: Connection reset by peer]
00:38 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
00:39 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
00:42 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:42 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
01:39 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
01:39 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 258 seconds]
01:51 -!- lowhope [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has quit [Remote host closed the connection]
01:54 -!- lowhope [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has joined #bitcoin-core-pr-reviews
02:04 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
02:45 -!- Macx [uid89142@id-89142.lymington.irccloud.com] has quit [Quit: Connection closed for inactivity]
03:01 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
03:56 -!- greypw2546002 [~greypw254@grey.pw] has quit [Quit: I'll be back!]
03:56 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
04:02 -!- ElBuda [~lontivero@186.183.64.23] has joined #bitcoin-core-pr-reviews
04:08 -!- ElBuda [~lontivero@186.183.64.23] has quit [Ping timeout: 268 seconds]
04:10 -!- ElBuda [~lontivero@186.141.231.96] has joined #bitcoin-core-pr-reviews
04:23 -!- ElBuda [~lontivero@186.141.231.96] has quit [Ping timeout: 252 seconds]
05:25 -!- ElBuda [~lontivero@186.183.68.4] has joined #bitcoin-core-pr-reviews
05:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6888:8a76:52b6:6f22] has joined #bitcoin-core-pr-reviews
05:58 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has joined #bitcoin-core-pr-reviews
06:48 -!- ElBuda [~lontivero@186.183.68.4] has quit [Ping timeout: 255 seconds]
06:50 -!- ElBuda [~lontivero@186.183.68.136] has joined #bitcoin-core-pr-reviews
06:52 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
06:56 -!- ElBuda [~lontivero@186.183.68.136] has quit [Ping timeout: 268 seconds]
06:57 -!- ElBuda [~lontivero@186.183.66.41] has joined #bitcoin-core-pr-reviews
07:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
07:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:29 -!- ariard [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews
07:36 -!- jamesob [~jamesob@pool-108-31-94-118.washdc.fios.verizon.net] has quit [Ping timeout: 244 seconds]
07:41 -!- ElBuda [~lontivero@186.183.66.41] has quit [Ping timeout: 268 seconds]
07:42 -!- ElBuda [~lontivero@186.183.64.252] has joined #bitcoin-core-pr-reviews
07:48 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
08:08 -!- ElBuda [~lontivero@186.183.64.252] has quit [Ping timeout: 268 seconds]
08:11 -!- ElBuda [~lontivero@186.141.231.53] has joined #bitcoin-core-pr-reviews
08:36 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
08:37 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
08:47 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:49 -!- ElBuda [~lontivero@186.141.231.53] has quit [Read error: Connection reset by peer]
08:55 -!- ElBuda [~lontivero@186.183.68.203] has joined #bitcoin-core-pr-reviews
09:01 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:07 -!- ubbabeck [uid566434@id-566434.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
09:09 -!- b_101 [~b_101@189.236.23.182] has joined #bitcoin-core-pr-reviews
09:13 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
09:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
09:31 -!- ElBuda_ [~lontivero@186.183.64.196] has joined #bitcoin-core-pr-reviews
09:32 -!- ElBuda [~lontivero@186.183.68.203] has quit [Ping timeout: 255 seconds]
09:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
09:41 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
09:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
09:44 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Connection closed]
09:48 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
10:00 < lightlike> #startmeeting
10:00 < stickies-v> hi
10:00 < lightlike> hi!
10:00 < b_101> hi
10:00 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
10:00 < ishaanam[m]> hi
10:00 < theStack> hi!
10:00 < BlueMoon> Hello!!
10:00 < ariard> hi!
10:00 < michaelfolkson> hi
10:00 < lightlike> Welcome to the review club - anyone here for the first time?
10:01 < Kaizen_Kintsugi_> Hi
10:01 < stratospher[m]> hi
10:02 < lightlike> Today's meeting is about #25600 by ariard. Notes and questions are at https://bitcoincore.reviews/25600.
10:02 < larryruane_> hi
10:02 < brunoerg> hi
10:02 < lightlike> Maybe to start, can someone summarize the changes of this PR?
10:02 -!- davidjumberj [~davidjumb@2600:1700:8d41:8880::13] has joined #bitcoin-core-pr-reviews
10:03 < Kaizen_Kintsugi_> Giving an option and nodes to prefer rbf
10:03 < larryruane_> we already have fullrbf functionality; this PR lets us have a better chance to connect to other fullrbf peers (instead of it being just luck)
10:04 < BlueMoon> An optional -mempoolfullrbfa Bitcoin Core parameter was added
10:04 -!- sanya [~sanya@178-223-40-133.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
10:04 < larryruane_> if we send a replacement tx to a non-fullrbf peer, it will ignore it, which isn't very useful
10:04 < lightlike> oh, and I almost forgot this - who got a chance to review this? (y/n)
10:04 < larryruane_> BlueMoon: I think that was added in an earlier PR
10:05 < larryruane_> y
10:05 < b_101> y
10:05 < davidjumberj> n
10:05 < theStack> y
10:05 < Kaizen_Kintsugi_> n
10:05 < BlueMoon> y
10:05 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:05 < stickies-v> n, just read the PR conversation, here to lurk & learn
10:05 < juancama> hi everyone
10:06 < stratospher[m]> y
10:06 < lightlike> Kaizen_Kintsugi_: larryruane_ : yes! 
10:06 < ishaanam[m]> I didn't review the code very carefully, I did more conceptual review
10:07 < larryruane_> there's not much code in this one! the hard part is all conceptual! lots of game theory kind of stuff, very interesting!
10:07 -!- pablomartin [~pablomart@185.199.100.6] has joined #bitcoin-core-pr-reviews
10:07 < theStack> concept ACK, given the assumption that full-rbf is important (didn't go over the mailing posts explaining the exact reasons for the need in detail...)
10:07 < BlueMoon> Thanks larryruane_ I didn't know it was in a previous one.
10:07 < lightlike> yes, the parameter was already added in #25353 - this PR goes one step further.
10:08 < b_101> larryruane: +1
10:08 < larryruane_> theStack: similar for me, I could not follow the complex reasoning in the mailing list, and a lot of what's on the PR
10:08 < lightlike> yes, I think for this PR the conceptual discussion is at least as important and difficult as the actual implementation.
10:08 < larryruane_> i'm just glad there are so many amazingly smart people working on this stuff who do!
10:09 < lightlike> So let's jump into the questions:
10:10 < lightlike> What network-level conditions must be fulfilled for full-RBF to “work”, i.e., facilitate the propagation of transactions that replace others not signaling BIP 125? Is it necessary that every node or the majority of nodes need to support it?
10:11 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
10:11 < larryruane_> I think the answer to Q2 is definitely no, but I don't know to quantify it .. it's like 6 degrees of Kevin Bacon kind of thing https://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon
10:11 < theStack> not sure if this was the intention of the question, but one of my initial thoughts was, that at the very least the miners have to support it, otherwise the replaced txs will never end up in blocks
10:11 < theStack> (of course, they have an incentive to do full-rbf, so that shouldn't be a problem)
10:11 < larryruane_> you don't have to have that many nodes that enable fullrbf to still get a lot of propagation
10:11 < stickies-v> a sufficient amount of nodes in the network need to have at least 1 full-RBF-route to a sufficient amount of miners, so definitely no need to have majority of nodes required
10:12 < Kaizen_Kintsugi_> I think the majority, if you are surrounded by nodes that aren't doing RBF, your transaction wouldn't be propagated by them, correct? I believe this would open up a subtle eclipse attack vector with enough plausable deniability.
10:12 < b_101> concept ACK, couldn't figure out from the discussions if the approach is safe
10:12 < glozow> oops hi! sorry i’m late
10:13 < Kaizen_Kintsugi_> hi
10:13 < lightlike> theStack: yes, at least some miners need to support it. Not necessarily every miner though.
10:13 < larryruane_> did someone do some simulation? that would be helpful -- IF you have a realistic model of network topology (that's the hard part I would think)
10:13 < brunoerg> stickies-v: +1
10:13 < stickies-v> theStack: yeah true need enough miners supporting it, however they're also directly incentivised  for enabling it though
10:14 -!- hmarino [~hmarino@190.220.129.220] has joined #bitcoin-core-pr-reviews
10:15 < instagibbs> if a miner somehow misses the "first" version, it may also make it through
10:15 < stickies-v> larryruane_: lightlike mentioned doing a simulation in https://github.com/bitcoin/bitcoin/pull/25600#pullrequestreview-1041170369
10:15 < Kaizen_Kintsugi_> Someone did do a simulation
10:15 < larryruane_> perhaps a subtle (or incorrect!) point: if the miners _always_ accept higher feerate replacements, always, then would they be setting themselves up to be DoSed?
10:15 < Kaizen_Kintsugi_> ah yes I was just going to paste that, thanks stickies
10:15 < lightlike> yes, I'd say that from a network perspective, all full-RBF connecting nodes (including the miner's nodes) should form a cluster, so that there is some path from each node to a miner.
10:15 -!- davidjumberj [~davidjumb@2600:1700:8d41:8880::13] has quit [Quit: Client closed]
10:16 < lightlike> * full-RBD supporting nodes
10:16 -!- davidjumberj [~davidjumb@2600:1700:8d41:8880::13] has joined #bitcoin-core-pr-reviews
10:16 < larryruane_> stickies-v: Kaizen_Kintsugi_ +1 thanks
10:16 < ariard> larryruane: there is the rbf penalty increased rule required for each replacement for that, rbf rule 4 in bip 125 parlance?
10:16 < stickies-v> larryruane_: that's assuming we know which nodes are miners?
10:16 < lightlike> yes, I did some simulations to get a feeling how many nodes would need to support full-RBF without any preferential peering.
10:16 < larryruane_> ariard: +1 good point
10:17 < glozow> larryruane_: this is related to signaling *only*, it doesn't apply to other RBF rules.
10:18 < larryruane_> glozow: +1
10:18 < glozow> i suppose this can also be achieved if people in the community running full RBF nodes connect to each other manually, and at least 1 of these nodes is a miner
10:19 < lightlike> glozow: yes, that's possible too.
10:19 < BlueMoon> glozow +1
10:19 < b_101> glozow: +1
10:19 -!- hmarino [~hmarino@190.220.129.220] has quit [Quit: Connection closed]
10:20 < glozow> of course not very robust or privacy-preserving but if you're desperate to replace something, maybe worth it?
10:20 < larryruane_> sorry if I'm getting ahead, but would this PR be considered just a step along the path to eventual default fullrbf?
10:20 < glozow> not really tbh, because it still requires users to turn it on. default is still off.
10:20 < ariard> glozow: there is also a centralization effect of the full-rbf topology as you're likely to rely on a social communication channel like irc, reddit, a gist, ...
10:21 < Kaizen_Kintsugi_> as an aside, it is surprising to me that this behaviour isn't default. But I am noob.
10:21 < lightlike> so in my simulations I got the result that without any preferential peering ~10-15% of supporting nodes would be necessary (which is not a lot, my intuition was expecting more like 30-40%).
10:21 -!- hmarino [~hmarino@190.220.129.220] has joined #bitcoin-core-pr-reviews
10:22 < lightlike> It seems unrealistic to me that that many users would choose an optional flag (at least without some big social media campaign or something...)
10:22 < glozow> ariard: yeah for sure. but also, you can probably trust your buddy on irc to run a "true" full rbf node more than you can trust a peer on the p2p network advertising NODE_FULL_RBF
10:22 < Kaizen_Kintsugi_> Hey lightlike, do you have a link to your simulation code? I'm curious of how a sim is built in bitcoin. Do you just use the functional testing framework?
10:22 < instagibbs> Interesting to note that it doesn't necessarily preferentially "Activate" based on a node's economic footprint.... which means sybils may be tempting...
10:22 < b_101> lightlike: agree
10:23 < instagibbs> To be clear, I'm against Sybiling the network, just noting how it's different from consensus changes
10:23 < sipa> i have a question: is the goal of this PR to (a) make "signal-less RBF" work for people who turn on the option, so they themselves can perform such transactions (b) to have the network "ease into" full-RBF relay if people turn it on, so it's easier to later argue that fullrbf can be made default, or something else?
10:23 < lightlike> Kaizen_Kintsugi_: Not right now, I can upload it later.
10:23 < sipa> And if it's just (a), why can't the people who we expect to turn this on not just signal RBF?
10:23 < Kaizen_Kintsugi_> no worries or rush, thx for indulging my curiousity
10:23 < ariard> glozow: yeah depends how you construct the social communication channel, if the full-rbf peers listed are comming from web-of-trust (and there i agree with you) or it's super liberal in listing
10:23 < larryruane_> Kaizen_Kintsugi_: I *think* the reason it wasn't always default is that it makes unconfirmed transactions less reliable ... the receiver can't know if it will be replaced, so doesn't trust it as much ... without RBF, the receiver can have a little more confidence that the tx will get mined
10:24 < sipa> (I haven't really followed all the discussions, feel free to point me somewhere if this was discussed before)
10:24 < larryruane_> (but I think the answer to what i said is that people shouldn't rely on mempool tx anyway!)
10:24 < BlueMoon> lightlike I would also like to see it :)
10:25 < b_101> lightlike: I'm akso interested in your work if you can share, thx
10:25 < ariard> sipa: so yes for a) the goal is to make "signal-less RBF" work for node opeators, without the additional work to do manual discovery of other full-rbf peers
10:25 < Kaizen_Kintsugi_> Thanks larry, that logic is a surprise to me as I always assume unconfirmed transactions are always unreliable.
10:25 < sipa> ariard: So in that case, why can't the people who care about this just set the RBF flag?
10:26 < sipa> (or expect those who pay them to do so)
10:26 < ariard> sipa: this is what this PR is actually achieving, activating service bit 26 for them
10:26 < instagibbs> sipa, defining "work" in (a) to mean "path from me to miner who opts in exists" imo
10:26 < Kaizen_Kintsugi_> Can you set the RBF flag and just drop replacement transactions just to be a jerk?
10:26 < instagibbs> ariard, why preferntial peering I think he means
10:26 < sipa> ariard: By RBF flag I mean the BIP125 opt-in.
10:26 < sipa> Not a P2P service flag.
10:26 < instagibbs> oh!
10:26 < larryruane_> sipa: I think the problem is that in LN, an *attacker* can *not* set the RBF flag, so then the good guy can't replace an evil tx
10:27 < larryruane_> (just got that impression from ML discussion but i don't really know)
10:27 < Kaizen_Kintsugi_> ah thanks for clearing that up larry
10:27 < ariard> about b) there is the idea of actually letting the network of nodes, and each individual operator, express a preferrence for full-rbf or not, without the project turning on a default 
10:27 < Kaizen_Kintsugi_> thats what I was wondering
10:27 < Kaizen_Kintsugi_> I really like this preferential peering acctually
10:28 < ariard> sipa: by the people who care you mean, the ones who cares about zero-conf transactions or the ones who care about full-rbf?
10:28 < Kaizen_Kintsugi_> kind of a soft vote on network behaviour
10:28 < sipa> ariard: Those who care about the ability to replace transactions.
10:28 < instagibbs> imagine a coinjoin, Alice races all other joiners with a non-signaling tx double-spending said coinjoin, now you might get stuck without seeing why, and replacements don't seem to work(except sending coin "back to self" to cancel)
10:28 < _aj_> ariard, sipa: i think the scenario is that you post a pre-signed commitment tx A, with low or 0 fees, and then an attacker announces a non-RBF tx B that supplies some fees (enabling relay) but not enough to get mined; at which point you can't replace A (because you don't have a different version of it) and can't replace B (because it's not RBF-opt-in, and doesn't inherit A's RBF-ness)?
10:28 < glozow> sipa: I think one scenario is a zeroconf LN funding, where they broadcast something conflicting with your channel open tx.
10:28 < lightlike> sipa: if only people who care set the flag, and that number is in the low % of nodes,  their transactions probably won't get relayed to a miner.
10:28 < ariard> larryruane_: yes, you can DoS the funding phase of a bunch of use-cases, at minimal cost (just have to pay over minimal mempool fee)
10:29 < lightlike> I'd assume most users don't care either way, but since the default no-full-RBF they will jsut go with it.
10:29 < ariard> sipa: so since #25353, those who care about the ability to replace transactions can do it so, however for the replacement to be effective on the p2p network wise, I think you need propagation paths to the miners, and a subset of them turning on the option too
10:29 < larryruane_> _aj_: thanks, ariard: thanks, very helpful explanations
10:30 < instagibbs> its a tricky DoS attack which shows that "opt in" isn't a free lunch, imo
10:31 < ariard> _aj_: yes this is the correct description of the issue, and affecting LN dual-funded, coinjoins, coinswaps, etc
10:31 < michaelfolkson> This PR feels like a stepping stone to turning on the default. Is there a strong enough argument for needing this stepping stone? I'm not sure
10:31 < ariard> note, the propagation of non-RBF tx B should be anterior to the pre-signed commitment tx A, which I believe is achievable by an attacker by mass-connecting and bypassing the privacy-preserving relay timers
10:31 -!- hmarino [~hmarino@190.220.129.220] has quit [Quit: Connection closed]
10:31 < glozow> _aj_: in that case adding a child to A and using package RBF should work, yes?
10:32 < instagibbs> glozow, no, B isn't "allowing" replacement
10:32 < sipa> TBH, my preference is just to make -mempoolrbf default at some point.
10:32 < ariard> glozow: depends if package RBF overrides the replacement signaling flag, can't remember the state of the package RBF design?
10:33 < instagibbs> michaelfolkson, my take: https://github.com/bitcoin/bitcoin/pull/25600#issuecomment-1230504946
10:33 < glozow> V3 must be replaced by V3, and V3 signals replaceability. also sorry, totally going off topic
10:33 < _aj_> glozow: not sure. add the constraint that only one of A's outputs is spendable immediately, and all the others have a "1 CSV" delay, perhaps
10:33 < lightlike> Next question (it's ok to continue the conceptual discussion in parallel):
10:33 < ariard> glozow: yeah so here you might have a conflict issue between the attacker fully-malleable transaction being V2 and your V3 package
10:34 < lightlike> This PR currently suggests to make 4 additional connections to full-RBF peers (1 in an earlier version). What should be considered when picking this number? What are the downsides of having too few / too many connections?
10:34 < larryruane_> this is really a tough one!
10:35 < sipa> I'm not sure why that number is acceptable. If 12 outbound connections is acceptable, we should always make them. If they're not, we shouldn't make them with or without -mempoolfullrbf.
10:35 < larryruane_> one obvious downside of too many connections is higher resource usage
10:35 < ariard> michaelfolkson: sure, we might have a number of node operators wishing to stay on opt-in RBF as a default, the idea of having automatic preferential peering you let of community of nodes operators express their own prefs
10:36 < glozow> ariard: yeah still screwed if it's e.g. a channel open and they get there first with a V2 non-BIP125
10:36 < instagibbs> sipa, for segwit pref peering, was it just making sure N were with segwit aware?
10:36 < instagibbs> when segwit was deploying, Core did preferential peering to segwit peers. So long ago I don't recall details.
10:36 < ariard> without the project contributors assuming what should be the default "a priori" and collecting more data points 
10:36 < sipa> instagibbs: yes
10:36 < larryruane_> sipa: that makes sense to me as well
10:37 < glozow> ariard: have you considered something like https://github.com/bitcoin/bitcoin/pull/10823? not mutually exclusive with this PR
10:37 < ariard> sipa: i think you have two questions, a) what should be the sufficient number of automatic outbound connections to have efficient propagation paths and b) is that sufficient number acceptable from a inbound slots resources consumptions viewpoint?
10:38 < lightlike> I think one problem with everyone making 12 connections is that we don't have enough inbound capacity for that. If just a few nodes (say <5%) have fullmempoolrbf enabled and do this, it might be less of a problem.
10:38 < sipa> I can see the rationale for adding connections rather than just preferential peering, as this means you don't get reduced connectivity to the rest of the network... but I don't think it's acceptable to just increase load on the network because of this.
10:39 < sipa> ariard: I don't have a strong opinion on the number 4, or how this peering is done. But I don't think we should just increase the number of connections just because. If 4 extra connections (or whatever you pick, even 1) is acceptable, why not make them always?
10:39 < ariard> glozow: yeah it was suggested to me last year by harding, iirc it didn't fix the DoS issue as the replacement timeout is in fact the DoS delay offered to the attacker
10:39 < _aj_> sipa: devil's advocate: you're only increasing load on the network that opts in to full rbf signalling?
10:39 < Kaizen_Kintsugi_> Is it reasonable to set a parameter that specifies a percentage of the operators connections to be of their preference, in this case full-rbf.
10:40 < sipa> _aj_: Unless some evil node on the network relays ADDR messages with the flag forcefully OR'ed in...?
10:40 < ariard> _aj_: i think this is how it should work, as you only connect to service bit 26 peers, if the node operators are okay with this usage of their inbound slots
10:41 < sipa> There is no way a node can prove that it's a full RBF peer, so you can't disconnect them if they turn out to not be a full RBF node while you though they would be.
10:41 < _aj_> sipa: hmm, either way, would be smart to disconnect if you want a peer that's full rbf, and you connect and it turns out it's not
10:41 < lightlike> sipa: that  (false signaling) is actually my next 2 questions :)
10:41 < glozow> ariard: that's true. they just grief you for N time instead of forever. but a reasonable step towards full rbf as default?
10:41 < lightlike> What happens if service flags (such as NODE_REPLACE_BY_FEE) a peer tells us in their version message are different from the service flags we had saved in AddrMan? Is the logic different when we learn from an addr message instead from the peer themselves?
10:42 < ariard> sipa: so if I understand correclty your point, the full-rbf peers should be deduce from the overall outbound connections budget we already have (the 8 outbound full-relay and the 2 outbound block-relay-only) ?
10:42 < _aj_> sipa: if they claim they're not a full-rbf peer (even if they're lying), that's a good enough reason to disconnect though?
10:42 < glozow> yeah exactly, our outbound slots are precious, so I'm not sure how i feel about preferring a type of outbound connection that we can't verify is legit
10:43 < sipa> Hmm, yes, if it's the case that we disconnect when we attempt to connect to fullrbf, but the peer then tells us they're not fullrbf somehow, then _aj_'s devil's advocate argument works.
10:43 < _aj_> sipa: that said, saying "connect to 4 random peers, 2 blocks-only peers, and the remaing 4 outbound connections must be full-rbf" seems like a better policy?
10:43 < sipa> Because in that case it is indeed so that -mempoolfullrbf is just opting in to both more extra outbound, AND extra inbound connections.
10:44 < Kaizen_Kintsugi_> Isn't falseified service flags solved with thompson sampling?
10:44 < ariard> sipa: well you could have automated replacement probing logic with GETDATA(replacement_txid), though somehow are we already doing assumptions by "trusting" the version announced by our peers, and the service supported? 
10:44 < ariard> like I could announce bip152 and never actually send you compact blocks
10:44 < instagibbs> _aj_, increased risk of eclipse attacks when number of rbf peers are low... in Segwit case, you REALLY WANT to connect to segwit outbound
10:44 < larryruane_> lightlike: "Is the logic different ..." yes, If we receive a version message from a node directly, we simply set our cache of its service bits directly.... if we hear about the node indirectly (addrman), we OR in the service bits
10:44 < larryruane_> I think that makes sense because the addr message that we receive could be out of date, so treat it as if it MIGHT have the flag enabled; we'll find out for sure when we connect
10:45 < _aj_> instagibbs: user-resisted-policy-change where everyone announces full-rbf-support but doesn't actually do it?
10:45 < ariard> glozow: well as it doesn't remove the grief, the full-rbf node operators wouldn't have an incentive to turn it on, I think it make it harder to build economic majority 
10:45 < glozow> ariard: but probing doesn't work either, what if they increased their incremental relay feerate and rejected the tx for a fee reason? we can't go around disconnecting peers for not having the same txns as us
10:45 < lightlike> larryruane_: exactly!
10:45 < ariard> at least full-rbf node operators interested to be protected against the multi-party funded transaction DoS thing
10:46 < lightlike> Next q: With this in mind, do you think that false signaling of a NODE_REPLACE_BY_FEE service flag could be problem? Could it be detected and punished?
10:46 < sipa> ariard: tx relay policy being unenforcable is a reason to not bother with any of this and just making -mempoolfullrbf default at some point, IMHO. It's weird to have a service flag for just a relay policy. Using this approach as a stepping stone to appease politics "but look it's already deployed and works" doesn't mean much: *of course* it'll work for nodes that turn this on. Doing this just to create effectively a secondary P2P network with fullrbf
10:46 < sipa> semantics isn't as useful as the real thing.
10:46 < instagibbs> _aj_, sybil group spins up signaling nodes :shrug:
10:46 < Kaizen_Kintsugi_> noob question: nodes don't advertise their relay fee rate?
10:46 < instagibbs> whoever these evil people are
10:46 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 258 seconds]
10:47 < instagibbs> maybe they actually relay double spends, but they're also slowing down blocks 
10:47 < instagibbs> Kaizen_Kintsugi_, they advertise a mempool minfee, "fee filter"
10:47 < sipa> Kaizen_Kintsugi_: Yes, BIP133. But that's the other way around: it is telling other nodes "don't bother sending me txn with fee below Y, because I'll just discard them anyway".
10:47 < sipa> It's a courtesy bandwidth optimization.
10:47 < Kaizen_Kintsugi_> ty insta & spia
10:48 < Kaizen_Kintsugi_> *sipa
10:48 < ariard> _aj_: from petertodd exp, apparently there wasn't evil full-rbf back in the days of 2015/2016 when actually that change was far more contentious
10:48 < larryruane_> sipa: does that enable fingerprinting attacks?
10:48 < lightlike> I think there are different ways of false signaling: Nodes that don't want full-RBF to work should (game-theoretically) false signal full-RBF, so that others looking for preferential peers will connect to them.
10:49 < sipa> game-theoretically, I think nodes should enable -mempoolfullrbf exactly based on 1 criterion: whether miners also do.
10:49 < instagibbs> lightlike, the response to this is mass-connecting to nodes to gossip double-spends :( 
10:49 < ariard> glozow: sure, i think we can never have absolute certainty of transaction acceptance at equivalent policy and resources setting (same mempool size) just becaouse you might have seen transactions, not seen on my side
10:49 < sipa> Oh, other kind of problem. Yeah, I agree with lightlike's point as well.
10:49 < ariard> we might at best increase the certainty
10:49 < glozow> larryruane_: the fee filter is not exact, so not really
10:50 < sipa> yeah the fee filter has some deliberate rounding in it to avoid being a huge fingerprinting vector.
10:51 < ariard> sipa: IMHO, this is where I'm differing in the sense that might have in the future controversial or not-clear-best-trade-off policy rules, adopting the release practice of offering options to node operators let us better accomodate an increasing variety of Bitcoin applications like L2, with different requirements 
10:51 < larryruane_> sipa: glozow: thanks, so it's a way to somewhat increase the anonymity set
10:51 < _aj_> so if the idea is "have a service bit, so that we can see how many people turn this feature on" and then say "oh, it's reached x% of the network and miners are mining it, we'll make it the default" -- there's less incentive for opponents to false signal support
10:51 < lightlike> also, there is the possibility of someone spamming the node with existing legit addrs, but adding the FULLRBF service bit to the existing legitimate sevice flags (so other nodes would add it in therir addrman).  If that happens, nodes might have problems to find legitimate full-RBF peers because everyone is full-RBF.
10:52 < lightlike> (I think that's what sipa said before)
10:52 < sipa> ariard: Operators already have that option, they can run other software. We should make software that works best for our users.
10:52 < davidjumberj> What are the concerns about full-RBF by default that make having an intermediate step beneficial?
10:53 < Kaizen_Kintsugi_> @_aj_: yea I like the idea of these softvotes
10:53 < glozow> _aj_: not sure if that's the idea? that's pretty sybil-able?
10:53 < ariard> sipa: and what are our users? a dynamic answer in function of new types of applications deployed
10:53 < instagibbs> davidjumberj, perhaps everyone in this room is mistaken, and all users actively reject the idea? status quo reigns
10:53 < sipa> If miners are permitting fullrbf, then so should bitcoin core.
10:54 < sipa> Whether that's the case today, I don't know.
10:54 < larryruane_> davidjumberj: that's a great question, the only thing I can think of is in case there's some attack or DoS that no one anticipated, so may be better to go slowly?
10:54 < ariard> _aj_: yes this is the idea, being able to observe in Y time how many X% of the network have turn it on, without us enforcing a default on our users, not necessarily matching their application requirements
10:54 < sipa> The point of the mempool is being a prediction for what will be mined. We should use all knowledge available to us to form that prediction.
10:54 < _aj_> sipa: (i'm confused: doesn't the VERSION message include the service bits, so you could verify if the addr was misleading/outdated that way?)
10:54 < ariard> instagibbs: exactly, perhaps all users or a strong set of them actively reject the idea
10:55 < _aj_> sipa: "If miners are permitting fullrbf," -- speedy trial time? :-P
10:55 < instagibbs> If an opt-in system goes forward and double-spending because easy(we can measure this?), then to me that's a non-rejection of the idea, and can become standard
10:55 < lightlike> sipa: is it known if  miners actually have an opinion on this? I'm afraids some might just lazily permit full-RBF as a reaction of bitcoin core making it the default?
10:55 < instagibbs> Maybe that's too cautious
10:55 < instagibbs> but that's an argument
10:55 < sipa> _aj_: Yes, that's what made me agree above with your devil's advocate argument. If the code does drop connections to intended fullrbf peers, which turn out to not be fullrbf peers (by their own claims), then my argument about increased resource usage goes away.
10:56 < glozow> if we told miners "hey, you can earn more fees if you use -mempoolfullrbf," would they not turn it on?
10:56 < Kaizen_Kintsugi_> I think they would
10:56 < sipa> I'd hope so, but I don't know.
10:56 < Kaizen_Kintsugi_> Does it impose a cost to them to do so?
10:56 < _aj_> sipa: aha, you said "tells us they're not fullrbf somehow" which i took to mean implying a new "FULLRBF" p2p message or something
10:56 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
10:56 < larryruane_> we don't really have a way to tell the miners anything, do we?
10:57 < BlueMoon> I also believe they would.
10:57 < ariard> _aj_: even if you enforce correspondence between version and addr service bits, the actual service offered by the service bits might be silently dropped or buggy by your peer
10:57 < instagibbs> larryruane_, in an ideal case we would never know who miners are and they would never know about protocol updates :P 
10:57 < sipa> ariard: "silently dropped" how? Buggy... yes, peers can be buggy, we don't need to serve them when they are.
10:58 < _aj_> glozow: the problem is others might say "fullrbf means our business will effectively shut down, and there'll be less bitcoin tx volume, so you'll make less money"
10:58 < ariard> glozow: yeah advocating the economic advantages of full-rbf to miners, something part of the full-rbf release process i think
10:59 < glozow> _aj_: I agree that's a concern, but think there are fewer and fewer businesses who absolutely cannot survive without relying on zeroconf. Or at least hope so 😅
10:59 < sipa> _aj_: It could be a separate message, or looking at the service bits they send in VERSION. I'm not sure if the latter is always reliable (do we always set them? even when we think we're not reachable etc)?
10:59 < ariard> instagibbs: "they would never know about protocol updates", well in the future miners might run multiple mempool, one for each RBF policy designable, as the economic efficiency of a RBF policy can be function of the transaction order of acceptance, i think
11:00 < lightlike> ok, wrapping up - (my last question was already discussed  anyway)
11:00 < lightlike> thanks everyone - great discussion!
11:00 < lightlike> #endmeeting
11:00 < instagibbs> ariard, I'm being a bit facetious 
11:00 < Kaizen_Kintsugi_> Thank you everyone
11:00 < davidjumberj> Thanks
11:00 < glozow> thanks lightlike!
11:00 < larryruane_> thanks @lightlike this was great!
11:00 < Kaizen_Kintsugi_> man, the more I learn about this project the more interesting it becomes
11:01 < ariard> sipa: i meant, i'm signaling full-rbf but i don't enforce the replacement on non-signaling transaction when I receive a replacement candidate from a full-rbf peer, i'm not sure it's observable
11:01 < _aj_> glozow: last year, ziggamon reported bitrefill does 0conf on 80% of their incoming txs, gated on them not being rbf-flagged (50/50 on the remainder being non-0conf due to signalling rbf or other metrics) https://twitter.com/ziggamon/status/1435863691816275970
11:02 < Kaizen_Kintsugi_> If any xp core devs would like to comment, I'm wondering about the social etiquite of contributions. I'm working on an pull-request of something I found that I feel that could be beneficial, but I'm wondering if I'm jumping the gun. Do more reviews or something.
11:03 < Kaizen_Kintsugi_> I see that there are a lot of pull requests, near 400, and I'm wondering if mine will just be buried as it is super minor
11:03 < sipa> ariard: Yes, that's a reason for still not liking this service-flag-for-relay-policy idea (which I think I still stand by). But my earlier argument relating to resource usage due to extra connections, and only that argument, disappears if we disconnect on mismatch between expected services and version services.
11:03 < instagibbs> Kaizen_Kintsugi_, start small, don't open a ton of PRs all at once, im sure you'll be fine
11:03 < Kaizen_Kintsugi_> okay thx insta
11:03 < Kaizen_Kintsugi_> this is a very small pr, only adjusts a single function
11:03 < instagibbs> be concious of reviewers/maintainers' time
11:03 < instagibbs> that's all
11:04 < Kaizen_Kintsugi_> yea thats what's i'm concerned about when I see these 400 requests
11:04 -!- pablomartin [~pablomart@185.199.100.6] has quit [Ping timeout: 255 seconds]
11:04 < _aj_> Kaizen_Kintsugi_: improve or add a test is the easiest way to get a win, in my opinion, for what it's worth
11:04 < Kaizen_Kintsugi_> _aj_: I am adding a test with this for sure
11:05 < instagibbs> anyways great discussion, learned quite a bit :)
11:05 < ariard> _aj_: I think offering to node operators the options to pickup their RBF options palliates for the lack of consistent methodology to measure the econnomic volume of zero-conf use-case vs multi-party funded (especially as this one is expected to be take in signifcance in the future), at least in a consensual way 
11:05 < ariard> like let's the community of node operators express their prefs
11:06 < Kaizen_Kintsugi_> So when doing a review, pull down the code, run it, review it and comment? That's all what I can really do for the review process as a noob?
11:06 < glozow> _aj_: wtf the original tweet 🤦‍♂️. yeah people always cite bitrefill. But like, we can't create a network where the LN users can always win against the time value DoSers AND bitrefill can rely on zeroconf transactions as long as they don't signal BIP125. either replacements without signaling propagate, or they don't. so we gotta figure out what to do right?
11:06 < larryruane_> did we ever answer the question of whether spoofing of this service bit can be detected (and thus maybe disconnect the peer)? (sorry if i missed it)
11:06 < Kaizen_Kintsugi_> larry: I suggested thompson sampling
11:07 < Kaizen_Kintsugi_> I think that would fix it
11:07 < Kaizen_Kintsugi_> over a long period of time
11:07 < _aj_> glozow: i think opt-in rbf is an unstable equilibrium; as soon as someone gets serious about relaying fullrbf, it's done; otoh, 80% non-rbf-signalling being fine for a business was kind of surprisingly high?
11:07 < sipa> larryruane_: If you mean mismatch between service bits in the addr message and version message, that's detectable (and I think it should be).
11:07 < Kaizen_Kintsugi_> https://en.wikipedia.org/wiki/Thompson_sampling
11:08 < sipa> Mismatch between version message bits and actual relay policy is non-observable, I think. There isn't a small fixed number of policies to choose from.
11:08 < ariard> sipa: Yes that's a valuable argument, that from a local node viewpoint you cannot have high reliability of the effective propagation of your full-rbf transactions. Again I wouldn't be surprised we already do this assumption of "service reliability" (?), either announced by service bit or "SENDFULLRBF", in our p2p stack.  
11:08 < lightlike> larryruane_: I don't think so. I think that false signaling can only detected by making multiple probing connections to a node (and check whether full-RBF get relayed), but not in the normal scenario of just being a node in the nodework.
11:08 < larryruane_> sipa: I'm thinking of a node whose service bit and *behavior* don't match
11:09 < larryruane_> lightlike: thanks
11:09 < sipa> Nodes are literally allowed to do anything at all, including ignore any transactions you send them.
11:10 < b_101> thanks to all, I always learn a lot!
11:10 < larryruane_> but (here's where my noobness shows) we don't mind if that's possible? we still at least somewhat assume that most nodes are honest? it doesn't disqualify the idea?
11:10 < ariard> glozow: from my knowledge, few zeroconf service operators have additional mitigations against zero-conf double-spend, like running and monitoring multiple mempools across the network
11:10 < sipa> For on-chain payment transactions that doesn't really matter. Worst case, your transaction doesn't go through. You can keep retrying.
11:11 < sipa> For applications built on top, like LN, which rely on timely confirmations, the situation is different - there actual monetary loss can result from non-confirmation. I'm not sure what the answer is, but relying on the P2P network is ugly.
11:11 < ariard> lightlike: i think multiple probing connections to a node, wouldn't be scalable network-wise in term of resources
11:13 < Kaizen_Kintsugi_> Thanks for doing tis ariard
11:13 < Kaizen_Kintsugi_> I really like your ideas.
11:13 < lightlike> ariard: I agree. It's something a researcher could to check how many nodes are false-signaling, but useless for a node that wants to make a decision whether to disconnect a peer for false-signaling right now.
11:15 < sipa> Right.
11:21 -!- sanya [~sanya@178-223-40-133.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
11:22 < BlueMoon> Thank you all, I have learned a lot.
11:22 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
11:23 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has quit [Ping timeout: 252 seconds]
11:26 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has joined #bitcoin-core-pr-reviews
11:32 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has quit [Ping timeout: 252 seconds]
11:37 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has joined #bitcoin-core-pr-reviews
11:41 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
11:53 -!- davidjumberj [~davidjumb@2600:1700:8d41:8880::13] has quit [Quit: Client closed]
12:06 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:09 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
12:10 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
12:16 < lightlike> anyone who wanted to have a look at my network simulations: https://github.com/mzumsande/fullrbf_simulation (I'll also edit a link into the PR comment)
12:47 -!- pablomartin [~pablomart@82.180.147.175] has joined #bitcoin-core-pr-reviews
12:48 -!- pablomartin [~pablomart@82.180.147.175] has quit [Client Quit]
13:06 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
13:27 -!- ElBuda_ [~lontivero@186.183.64.196] has quit [Ping timeout: 240 seconds]
14:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6888:8a76:52b6:6f22] has quit []
14:26 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
14:28 -!- asi0 [~asi0@static-176-191-113-38.ftth.abo.bbox.fr] has joined #bitcoin-core-pr-reviews
14:29 -!- asi0 [~asi0@static-176-191-113-38.ftth.abo.bbox.fr] has quit [Client Quit]
14:31 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
15:07 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
15:58 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:01 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:02 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
16:03 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 244 seconds]
16:05 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:06 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
16:10 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
16:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:58 -!- Kaizen_K_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:01 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
17:14 -!- aryan_ [~aryan@cpe-67-250-75-104.nj.res.rr.com] has joined #bitcoin-core-pr-reviews
17:14 -!- aryan_ [~aryan@cpe-67-250-75-104.nj.res.rr.com] has quit [Client Quit]
17:36 < Kaizen_K_> ANyone here, what version of python do people use to run the python testing framework?
17:37 < Kaizen_K_> I'm running on 3.8 and 3.6 and getting an error that the bdb module doesn't have an attribute of Bdb
17:38 < sipa> https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md says 3.6
17:38 < sipa> that may be a problem with the bdb module you have installed, rather than with python
17:44 < Kaizen_K_> hmm I'm on a fresh env using anaconda
17:44 < Kaizen_K_> bdb is being refed from pdb
17:45 < Kaizen_K_> thanks for the insight anyhow
17:47 < Kaizen_K_> yea its an anaconda problem damn
17:53 -!- ElBuda_ [~lontivero@186.183.67.38] has joined #bitcoin-core-pr-reviews
17:56 < Kaizen_K_> ahhhh I think this is from skipping the berkleydb, i configured withoutit
17:56 < Kaizen_K_> didnt think I needed it
17:56 < Kaizen_K_> and that it was old
18:17 < Kaizen_K_> gah, bdb.py in test frameworks is clobbering native bdb
18:30 -!- Kaizen_K_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Remote host closed the connection]
18:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
18:45 -!- ElBuda_ [~lontivero@186.183.67.38] has quit [Ping timeout: 252 seconds]
18:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Remote host closed the connection]
18:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:06 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds]
19:21 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Remote host closed the connection]
19:22 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:28 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 240 seconds]
20:01 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
20:23 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Remote host closed the connection]
20:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
20:32 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 240 seconds]
20:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
20:53 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
21:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2001:569:731c:2c00:bdac:4c11:e1a4:edff] has joined #bitcoin-core-pr-reviews
21:05 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2001:569:731c:2c00:bdac:4c11:e1a4:edff] has quit [Ping timeout: 240 seconds]
21:25 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 252 seconds]
21:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:40 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 268 seconds]
21:56 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
21:58 -!- kevkevin [~kevkevin@2601:243:197e:8f10:a91b:9ce0:4f0b:fde] has quit [Ping timeout: 252 seconds]
22:12 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
22:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
22:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
22:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9qjil159ozzbwbuq9ddr.ipv6.telus.net] has quit [Ping timeout: 240 seconds]
23:32 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
23:33 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Sep 01 00:00:06 2022