--- Log opened Wed Feb 09 00:00:54 2022
00:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 256 seconds]
01:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
02:05 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
02:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 250 seconds]
02:38 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
03:04 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
03:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d10d:5552:e289:da04] has joined #bitcoin-core-pr-reviews
05:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d10d:5552:e289:da04] has quit [Remote host closed the connection]
05:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
06:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Remote host closed the connection]
07:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
07:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 245 seconds]
07:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
08:18 -!- rage-proof [~rage-proo@ip5f5bd3d9.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews
08:24 -!- Franklin [~Franklin@197.210.227.171] has joined #bitcoin-core-pr-reviews
08:30 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
08:40 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]
08:45 -!- Franklin [~Franklin@197.210.227.171] has quit [Ping timeout: 260 seconds]
08:53 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:55 -!- Franklin [~Franklin@197.210.54.143] has joined #bitcoin-core-pr-reviews
08:57 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:00 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has joined #bitcoin-core-pr-reviews
09:00 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
09:00 -!- hashfuncd0d [~user@162.254.115.155] has joined #bitcoin-core-pr-reviews
09:00 < glozow> hello?
09:00 < glozow> #startmeeting
09:00 < b10c> hi
09:00 < lightlike> hi
09:00 < michaelfolkson> hi
09:00 < svav> Hi
09:00 < bitcoin1o1> hi all
09:00 < emzy> hi
09:00 < theStack_> hi
09:01 < glozow> Welcome to PR review club everyone! Today is package CPFP day: https://bitcoincore.reviews/24152
09:01 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:01 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-pr-reviews
09:01 < glozow> did anyone get a chance to review the PR or read the notes? how about a y/n?
09:01 < effexzi> Hi every1
09:01 < emzy> n
09:01 < larryruane> gm!
09:01 -!- bit-pleb-paul [~bit-pleb-@24.114.111.60] has joined #bitcoin-core-pr-reviews
09:01 < effexzi> N
09:01 < b10c> n
09:02 < svav> Read the notes
09:02 < bit-pleb-paul> Hi
09:02 < lightlike> y
09:02 < bitcoin1o1> n
09:02 < larryruane> 0.6y
09:02 < bit-pleb-paul> read the notes
09:02 < Ludwig> n
09:02 < theStack_> n
09:02 -!- Franklin [~Franklin@197.210.54.143] has quit [Ping timeout: 256 seconds]
09:02 < michaelfolkson> y Read notes, built, run unit tests etc
09:02 < glozow>  since a lot of us haven't reviewed the PR, could someone summarize what it does?
09:03 -!- kalpa [~kalpa@ip-005-146-160-032.um05.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
09:03 < glozow> (or take a guess?)
09:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Remote host closed the connection]
09:03 < svav> It is centered around creating an incentive-compatible policy for assessing package feerates.
09:03 < glozow> svav: yep!
09:03 < neha> hi
09:04 < glozow> can you give an example of what this policy enables?
09:04 < larryruane> when evaluating a package, instead of just checking the overall package feerate, look inside and check the individual tx first, accept any as individuals if possible, then check the (reduced) package (what's remaining0
09:04 < svav> Basically to make sure incentives for miners will work for packages.
09:04 < glozow> larryruane: yes, that's also a part of this pr!
09:05 < larryruane> and I think the part I mentioned has to do with exactly that, making things miner incentive-compatible
09:05 -!- tarun [~tarun@cpe-174-97-2-41.cinci.res.rr.com] has joined #bitcoin-core-pr-reviews
09:05 < svav> A basic question - what is the rationale behind wanting to have packages in Bitcoin at all? Is it just to help low fee transactions get processed?
09:06 < bit-pleb-paul> It’s for lightning - I’ll elaborate - I’ll be typing with my thumbs today
09:06 < glozow> svav: good question! here's a link for full motivation: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#package-relay-and-package-mempool-accept
09:07 < larryruane> svav: that's a great question, maybe I can make an attempt... Suppose you have a tx that has SUCH a low fee that mempools won't even accept it at all ... and you don't have the ability to create a new tx, you only have that one ... so with package feature, you can combine it with a high fee child and get them both accepted
09:07 < glozow> good answer larryruane
09:07 < larryruane> (if the mempool won't accept it at all, then it's impossible to fee-bump it with CPFP)
09:07 < glozow> so one example is, if your mempool is full and the minimum feerate is higher than the feerate of an individual transaction, right now you won't be able to use CPFP to broadcast it, because we only consider transactions individually
09:08 < glozow> oops larryruane beat me to it :P
09:08 < larryruane> this was mentioned in the brink podcasts (the second one I believe), which everyone should listen to! https://brink.dev/podcast
09:09 < emzy> it's an chicken and egg problem.
09:10 < bit-pleb-paul> In regards to lightning - if a channel is force closed by one party, but the closing transaction doesn’t have a high enough fee, it  won’t even be accepted into the mempool, as described above. Thereby lightning force closures wouldn’t work, and I the outcome of that, I think, is that counterpartoes could steal funds
09:10 < glozow> bit-pleb-paul: indeed. commitment transactions also cannot replace each other via RBF, and if the feerate isn't enough to make it into the mempool, your hands are tied
09:10 < larryruane> You may be wondering why would someone create a tx with such a low feerate that it won't even be accepted into the mempool (much less mined)? I think the answer is that this tx may have been created months ago when fees were very low, and now fees are much higher, and we can't *change* the tx ... I think this happens with Lightning?
09:11 < glozow> larryruane: correct, fees are negotiated with your counterparty beforehand. not months ago, but yes you could have underestimated
09:11 < larryruane> (this idea that you HOLD a transaction, that you can't modify, for a long time, is common with L2 stuff)
09:12 < glozow> with package relay and the policy in this PR, you could actually just put 0 fees on the commitment transaction and adjust your fee-bump based on the current feerate market when you go to broadcast it
09:12 < glozow> that's further into the future though.
09:12 < glozow> emzy: what do you mean by chicken and egg problem?
09:12 < glozow> just curious
09:13 < ziggie> hi
09:13 < svav> With a Child Pays for Parent Transaction being used to bump another transaction, is the Child transaction always initiated by the same person that sent the parent transaction?
09:14 < emzy> glozow: you can't get the low fee transaction in and you can't get the CPFP transacion in. 
09:14 < larryruane> glozow: very cool, I guess the tradeoff is, if you try to estimate a fee ahead of time, and it turns out to be enough, then you can save overall fees because you don't need that child ... whereas, if you create the tx with 0 fee, then it's guaranteed you'll need a child - 2 transactions, more expensive
09:14 < glozow> and anyone else, feel free to ask more questions about motivation, i'm happy to describe further. the PR isn't very exciting if we don't know why we're doing this
09:14 < glozow> svav: nope! if the parent is a payment, the child could be created by either the sender (from their change output) or recipient (from their payment output)
09:15 < glozow> emzy: oh yes i see what you mean now 🧠
09:16 < larryruane> svav: if the sender wants to change the fee, he or she has the option of RBF, which probably is a little cheaper overall (other things equal)
09:16 -!- Franklin [~Franklin@197.210.227.171] has joined #bitcoin-core-pr-reviews
09:16 -!- Ludwig [~Ludwig@cpe-67-49-78-121.dc.res.rr.com] has quit [Quit: Connection closed]
09:16 < glozow> larryruane: that's true. the counterargument is: if you estimate the fees ahead of time, you could end up overestimating and wasting money.
09:16 < ziggie> so this package is only a package for relaying, in the mempool the structure stays the same as of today ? And as soon as a tx is in the mempool other rules to accept it into a block apply ?
09:16 < larryruane> glozow: +1
09:16 < michaelfolkson> What sort of DoS vectors are there with CPFP (if any)? I'm in RBF mode and I'm trying to get into CPFP mode :)
09:17 < glozow> ziggie: correct, there would be no changes to the mempool data structure itself. our block template building logic has used CPFP since at least the past few years
09:17 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
09:17 < ziggie> glozow thanks
09:18 < theStack_> why is RBF not possible for lightning commitment transactions? is it because we would need a signature from the channel partner, which is possibly not able to cooperate (or not online at all)?
09:18 < larryruane> theStack_: maybe it's more a problem for the settlement tx?
09:18 < glozow> michaelfolkson: that's a good question, since DoS is a very front-and-center concern when looking at this area of the code. but i think incentive compatibility and preventing censorship are a more relevant concerns for package cpfp specifically.
09:19 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:19 -!- observer52 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
09:19 < ziggie> theStack_as soon as you are using a lightning commitment tx your are "unilateraly closing channel" so no way to get a newer transaction (RBF) with more fees
09:19 < ziggie> because peer is unavailable
09:20 < glozow> theStack_: correct. for one commitment tx to replace the other, it would need to have pretty significantly higher fees. since you negotiated the fees ahead of time (and they would be the same for both you and your counterparty's tx) and you can't get them to sign a new one, it's not possible.
09:20 < theStack_> larryruane: hmm isn't the commitment transaction (also called refunding transaction afaik) what you mean by "settlement tx"?
09:20 < bit-pleb-paul> I really liked the incentive where a child with no fee ought not be able to ‘dragdown’ a parent from entering the mempool (by not increasing the fee while increasing the vybtes )
09:20 < bit-pleb-paul> This seems like an anti DoS incentive
09:20 < theStack_> ziggie: glozow: ok thanks, that makes sense
09:21 < larryruane> theStack_: you're probably correct, I'm lightning-challenged :)
09:22 < glozow> bit-pleb-paul: thanks! :) i wouldn't call that a DoS (it's not exhausting resources), but censorship. somebody shouldn't be able to get your transaction rejected just by adding a low-feerate child to it and sending them as a package.
09:22 < theStack_> larryruane: heh, me too, actually. i'm planning to read "mastering lightning" soon to hopelly change that :D
09:22 < theStack_> *hopefully
09:23 < michaelfolkson> There is a commitment transaction that can be broadcast to close a channel unilaterally and a justice transaction if your counterparty broadcasts an old commitment transaction
09:23 < glozow> i learned most of my lightning info from here: https://chaincode.gitbook.io/seminars/lightning-protocol-development
09:23 < ziggie> can somebody explain why we are removing transactions from the package which are valid without the package, it it not better for the package to be higher in feerate ?
09:24 < bit-pleb-paul> question - what are siblings? Any two txs in the same block?
09:24 < glozow> bit-pleb-paul: transactions that share a parent
09:24 < lightlike> why couldn't the original transaction be several months (or even years) old until it needed to be CPFP'ed? surely lighting channels could stay open that long?
09:24 < bit-pleb-paul> +1 ziggies question
09:25 < bit-pleb-paul> @light I believe they can be that old, they just generally aren’t
09:25 < glozow> lightlike: oh yes true, it could be months old if it's from a very old state e.g. when the counterparty had a much higher balance. i guess i didn't really imagine that happening normally
09:26 < larryruane> ziggie: i think "better" is a complicated concept here, if one thing is better, everything else is relatively slightly worse, so may not get mined (or possibly even get evicted from the mempool) ... but that's still a good question!
09:26 < theStack_> glozow: thx for the chaincode seminar link, that seems to be a good learning resource
09:27 < michaelfolkson> Can we do the questions from the notes? :)
09:27 < glozow> ziggie: very good question, it's one of the questions in the notes, so let's just move on to those
09:27 < larryruane> 1. concept ACK from me for sure, the code looks solid, i would need to review more
09:27 < glozow> first question: Define package feerate, in your own words.
09:28 < larryruane> total fees divided by total vbytes ... which may be very different from the individual tx feerates!
09:28 < glozow> larryruane: great answer
09:29 < glozow> let's have an example. Let’s say we have transactions {A, B, C, D} where {A, B, C} are parents of D. For simplification, transactions are 100vB. All {A, B, C} pay 0 fees, and D pays 30,000sat in fees.
09:29 < glozow> what's the package feerate of package {A, B, C, D} ?
09:30 < theStack_> first naive try: 30000 sats / 400 vb = 75 sats/vb
09:30 < bitcoin1o1> glozow: 75 ?
09:30 < glozow> theStack: bitcoin1o1: exactly
09:30 < bit-pleb-paul> Without thr prioritise tx bumps?
09:31 < larryruane> (I like the way you name those, A-D, very small suggestion, in the new packages.md text, they're the other way around, B is the parent and A is the child, maybe reverse those?)
09:31 < glozow> very good. let's say, before submitting, we call `prioritisetransaction(D, +10,000sat)`. what's the package feerate now?
09:32 < theStack_> 40000 sats / 400 vb = 100 sats/vb ?
09:32 < glozow> theStack_: bingo
09:33 < glozow> ok and what if, before submitting, we call `prioritisetransaction(A, +100,000sat)` ?
09:33 < ziggie> We assume non of the transaction is in any mempool of node right now ?
09:33 < bit-pleb-paul> 140,000/400
09:33 < glozow> (in this scenario we didn't prioritise D)
09:33 < bit-pleb-paul> Oh
09:33 < glozow> ziggie: very good question, assume that none are in the mempool for this one
09:33 < glozow> but followup question: what is the package feerate if A and B are already in the mempool and we submit {A, B, C, D} ?
09:34 < bit-pleb-paul> They would remove A and B from thr package
09:34 < bit-pleb-paul> So
09:34 < ziggie> (in this scenario we didn't prioritise D) still 100
09:35 < ziggie> A gets out of the package I guess
09:35 < bit-pleb-paul> 100000sats/200vbytes?
09:35 < glozow> ziggie: yes exactly! A is validated first, so we end up only using {B, C, D} in the package feerate calculation.
09:36 < bit-pleb-paul> Why is A removed from the pckage while B remains?
09:36 < ziggie> only A is valid, B has still 0 fees ?
09:37 < glozow> yep, thank you ziggie. we validate all transactions individually first, and then try as a package. this ensures that ancestors don't pay for descendants
09:37 < neha> i'm confused as well :) A and B have 0 fees -- how did they get in the mempool?
09:37 < glozow> to illustrate this, look at this example: let's consider a package where the parent is high feerate and the child is low feerate: https://github.com/glozow/bitcoin-notes/blob/master/mempool_garden/package_rich_parent.png
09:37 < glozow> A was prioritized - its fee was modified with +100,000 when we called `prioritisetransaction()`
09:37 < bit-pleb-paul> I think in this case A had a setpriority from the miners
09:38 < neha> ah, ok, missed that we were considering the prioritisetransaction for A. thanks!
09:38 < glozow> neha: okay whew! glad that you clarified
09:38 < neha> i suppose we assume the node operator just felt like including B?
09:39 < ziggie> are  we answering the why later for this "excluding A" from the package
09:39 < glozow> B is submitted as a package with C and D. D pays 30,000sat fees, so the package feerate is 30000sat/300vB
09:39 < theStack_> ok we only want child-pays-for-parent, but not parent-pays-for-child... that makes sense
09:40 < bitcoin1o1> cause A is a parent?
09:40 < ziggie> theStack_ good point 
09:41 -!- justlistening [~justliste@pool-100-33-66-176.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
09:41 < glozow> theStack_: yes exactly. in general, a transaction B should only "pay for" another transaction A if B requires A in order to be mined.
09:41 < glozow> i hope that assertion makes sense to everyone
09:42 < glozow> bitcoin1o1: sorry i'm not sure what you're referring to?
09:42 < ziggie> yeah very clear now thanks glozow
09:42 < svav> In this diagram https://github.com/glozow/bitcoin-notes/blob/master/mempool_garden/package_rich_parent.png .... P2 shows 0 sat. Does this mean 0 sat in fees? Isn't there a min fee rate that all transactions must adhere to?
09:42 < glozow> svav: yes, P2 should be rejected.
09:43 < bit-pleb-paul> If a user wanted to send a tip on chain, couldn't they piggyback onto a parent as a lower child? Seems like a legitimate usecase
09:43 < svav> glozow In your examples are the fees you show the standard default fees set by the user rather than any discretionary prioritisation fees?
09:43 < theStack_> isn't another other issue that bumping A would change its txid and therefore the outpoint for the child's input, needing to resign the child tx?
09:43 < bit-pleb-paul> Like a tip at a bar* or something
09:44 < glozow> svav: that is the simplest example for why we first validate individually, to eliminate the parents from the package if they don't need to be paid for.
09:44 < michaelfolkson> [17:41:13]  <glozow> theStack_: yes exactly. in general, a transaction B should only "pay for" another transaction A if B requires A in order to be mined.
09:44 < glozow> and yes they are base fees, with no modifications unless specified
09:45 < larryruane> bit-pleb-paul: there would be no need for the tip to be a child, right? it could be just a separate tx?
09:45 < lightlike> bit-pleb-paul: but they need to be able to build a package with the parent, so they need to be the sender or receiver. they can't just tip random transactions they like.
09:45 < michaelfolkson> The point is we only try the package logic after trying the individual tx logic right?
09:45 < michaelfolkson> If the individual tx has enough fee it gets into mempool on its own
09:45 < glozow> right. there's no reason why the tip should be a child. it could be a separate transaction or, better yet, the sender should just create a replacement with the new payment value.
09:45 < emzy> bit-pleb-paul: the tip example still works. But the package to get in the mempool is not needed.
09:46 < bit-pleb-paul> glozow the replacement tx is a better idea, you're right
09:46 < glozow> michaelfolkson: yes. the only reason to consider package feerate together is for descendants to pay for ancestors. the nice thing about only allowing child-with-parents packages is that simply validating them individually first achieves this.
09:46 < emzy> bit-pleb-paul: the parent can go in the mempool alone.
09:47 < neha> bit-pleb-paul: the intuition i use is that running a node incurs a cost, and you want people proposing txns to pay for the resources they use. the only way we can do that before txn confirmation is to only really consider things that have a chance of getting confirmed on chain, where the txn proposer will have to pay a fee. otherwise, an attacker could create a lot of work for a node "for 
09:47 < neha> free"
09:48 < neha> so consider your tips in that analogy -- we don't want there to be a way for a transaction proposer to create a bunch of low-feerate txns without the required cost of paying something higher fee at some point. otherwise, people could spam nodes with low-feerate tips.
09:48 < bit-pleb-paul> neha thx
09:49 < larryruane> michaelfolkson: "... only allowing child-with-parents packages ..." You bring up a point I wanted to confirm, even with this PR (and the package relay ones that came previously), the full DAG package isn't supported, right? It's restricted to just 2 levels, and more than that, a single child with possibly many parents?
09:50 < glozow> the biggest reason why this works is because we only allow child-with-parents packages. "validate each individually first" is equivalent "validate all ancestors individually first," which eliminates the problem of ancestor-paying-for-descendant, and we can just use a package feerate
09:50 < larryruane> but later we'll allow the more general DAG?
09:50 < svav> Can we whizz through the rest of the questions?
09:50 < glozow> equivalent to*
09:50 -!- kalpa [~kalpa@ip-005-146-160-032.um05.pools.vodafone-ip.de] has quit [Quit: Leaving]
09:50 < glozow> ok sure. Would this definition of package feerate work for all types of packages? For example, packages with three generations, a parent with multiple children, unrelated transactions, etc.
09:51 < larryruane> glozow: i *think* so
09:52 < svav> My guess is yes because it has to cover all eventualities???
09:52 < lightlike> no. it might be incentive-compatible to just accept the parent and a child of the first generation, but discard all children later generations, so it would need a more sophisticated definition.
09:52 < glozow> no, it doesn't haha
09:52 < ziggie> I think the one with more than one generation is the problem
09:52 < glozow> lightlike: exactly. package feerate in this definition is ignorant of topology, which is crucial when we're thinking about incentive compatibility of multiple transactions.
09:52 < larryruane> lightlike: +1 good point!
09:53 < neha> is there a need to accept packages with more complex topologies?
09:53 < glozow> like we've talked about multiple times, unless there is a dependency relationship, there's no reason why another transaction's fees should be relevant in validation
09:53 < neha> or do the current child/parent packages handle all the, for example, L2 use cases you'e heard of?
09:54 < glozow> neha: good question. luckily no, according to everyone i've talked to
09:54 < neha> that's great!
09:54 < bit-pleb-paul> What would happen if a child's fee were still to low, due to user error, e.g. lowballing? The child would simply be replaced by another?
09:54 < glozow> mailing list discussion thread here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
09:55 < glozow> next question is
09:55 < glozow> Do you agree with the 6 incentive-related behaviors described in the notes above (https://bitcoincore.reviews/24152)? Can you think of anything missing?
09:56 < michaelfolkson> "Discourage “parent pays for child” and “sibling pays for sibling” behavior." sounds strong from previous discussion
09:56 < glozow> great!
09:57 < michaelfolkson> It isn't discourage, it is only check this once you've checked individually
09:57 < michaelfolkson> Oh I mean too strong lol 
09:57 < michaelfolkson> Right?
09:57 < glozow> er, what do you mean by too strong?
09:58 < michaelfolkson> I guess its a nit on the word "discourage"
09:58 < neha> can't a txn's feerate be harmed by a non-ancestor if it conflicts out one of their ancestors? or children?
09:58 < michaelfolkson> If it is just handled by the code logic the user isn't being discouraged, it is just a code logic ordering issue
09:58 < neha> or maybe i'm misunderstanding "harm"
09:59 < neha> this is wrt #5
09:59 < glozow> neha: ah yes that's a very good observation! we'll get to that with package RBF. but at this point, no conflicts are allowed in package validation.
09:59 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:00 < glozow> michaelfolkson: the ordering of the code here affects the outcome.
10:00 < svav> How come this PR has no reviewers yet? Is it too new or are people not interested in reviewing?
10:00 < larryruane> hey let's all review it!!
10:01 < glozow> svav: afraid i am unable to answer that question :'(
10:01 < ziggie> larryruane +1
10:01 < michaelfolkson> glozow: Hmm ok, I think I understand. It is in the user's interest to try to get the individual tx in the mempool first?
10:01 < neha> thank you glozow!
10:01 < glozow> feel free to also ask questions on the PR, those would be valuable to both me and other future reviewers who might have the same question
10:01 < glozow> #endmeeting
10:02 < larryruane> thank you glozow! this was really great!
10:02 < theStack_> thanks for hosting glozow!
10:02 < emzy> thank you glozow!
10:02 < lightlike> thanks!
10:02 < tarun> thank you.
10:02 < bitcoin1o1> thank you all
10:02 < glozow> thank you all for coming!
10:02 < ziggie> thank you glozow !
10:02 < bit-pleb-paul> Thanks glozow!
10:02 < svav> Thanks glozow and all
10:02 < michaelfolkson> Thanks glozow! Nice work on the series, missed all the progress you've made on this https://github.com/bitcoin/bitcoin/pull/22290
10:02 -!- bit-pleb-paul [~bit-pleb-@24.114.111.60] has quit [Quit: Connection closed]
10:03 < glozow> sorry that we didn't end up going through the questions serially. i didn't really know how much background people would have. hopefully this session helped people understand the PR though; that's the goal
10:04 < glozow> michaelfolkson: yes it's very exciting! i think i've spent about 500 hours on this now
10:04 < glozow> sometimes i dream that i'm swimming in a mempool and there's packages floating around
10:04 < michaelfolkson> This week's shill is glozow's presentation at Adopting Bitcoin on "Transaction Relay Policy for L2 Developers" https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/
10:05 < lightlike> svav: there is 1 reviewer now (myself)
10:05 < michaelfolkson> Package CPFP can be totally completed while we wait for RBF rules to be finalized?
10:05 < larryruane> michaelfolkson: +1 that was an excellent presentation!
10:06 < glozow> thank you 😊
10:06 < glozow> michaelfolkson: yes, we can make progress on both in parallel.
10:06 < glozow> thank you for the transcript!
10:06 < svav> lightlike: (y)
10:07 < michaelfolkson> No worries, was very good. Probably need to read it again on CPFP DoS vectors
10:07 < glozow> lightlike: 🙌 🙏 thank youuuu
10:09 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:10 -!- observer52 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed]
10:12 < glozow> oh btw, lightlike is hosting next week! on https://github.com/bitcoin/bitcoin/pull/23542
10:13 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has quit [Ping timeout: 256 seconds]
10:19 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has joined #bitcoin-core-pr-reviews
10:30 -!- hashfuncd0d [~user@162.254.115.155] has quit [Ping timeout: 256 seconds]
10:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Remote host closed the connection]
10:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
10:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 240 seconds]
10:46 -!- tarun [~tarun@cpe-174-97-2-41.cinci.res.rr.com] has quit [Quit: Konversation terminated!]
10:53 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:55 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:00 -!- hashfuncd0d [~user@162.254.115.155] has joined #bitcoin-core-pr-reviews
11:10 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:11 -!- Franklin [~Franklin@197.210.227.171] has quit [Ping timeout: 256 seconds]
11:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
11:15 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:33 -!- jesseposner [~jesse@user/jesseposner] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:53 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
11:54 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
12:06 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has quit [Ping timeout: 250 seconds]
12:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 268 seconds]
12:19 -!- rage-proof [~rage-proo@ip5f5bd3d9.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed]
12:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 250 seconds]
13:37 -!- Kaizen_K_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
13:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te51weecf8zdv48.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
13:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 240 seconds]
13:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
14:33 -!- Kaizen_K_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Remote host closed the connection]
14:34 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
14:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 256 seconds]
14:40 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
15:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 245 seconds]
15:05 -!- hashfuncd0d [~user@162.254.115.155] has quit [Ping timeout: 256 seconds]
15:05 -!- gleb7454386 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews
15:06 -!- gleb74543862 [~gleb@178.150.137.228] has quit [Ping timeout: 256 seconds]
15:07 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Remote host closed the connection]
15:08 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
15:12 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
15:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
15:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Remote host closed the connection]
15:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
15:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
15:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 260 seconds]
15:38 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
15:42 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds]
15:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
15:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 240 seconds]
15:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
16:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Remote host closed the connection]
16:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
16:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 260 seconds]
16:28 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
16:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 250 seconds]
16:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
16:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Remote host closed the connection]
16:53 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
16:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
17:16 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 240 seconds]
17:16 -!- rex_123[m] [~rex123mat@2001:470:69fc:105::1:83a2] has quit [Ping timeout: 240 seconds]
17:17 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-pr-reviews
17:17 -!- rex_123[m] [~rex123mat@2001:470:69fc:105::1:83a2] has joined #bitcoin-core-pr-reviews
17:19 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 256 seconds]
17:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 240 seconds]
17:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
17:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:55 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
18:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 250 seconds]
18:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
19:11 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
19:15 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
19:44 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-pr-reviews
19:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
20:11 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
20:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 240 seconds]
20:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has joined #bitcoin-core-pr-reviews
21:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
21:19 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:22 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:23 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
21:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 256 seconds]
21:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6449:599b:55bc:30d0] has quit [Ping timeout: 250 seconds]
21:44 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
22:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:fd49:eb7b:9a3e:b722] has joined #bitcoin-core-pr-reviews
22:49 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
23:02 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
23:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:fd49:eb7b:9a3e:b722] has quit [Ping timeout: 240 seconds]
23:06 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has quit [Ping timeout: 240 seconds]
23:11 -!- ziggie [uid521459@user/ziggie] has quit [Quit: Connection closed for inactivity]
23:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:fd49:eb7b:9a3e:b722] has joined #bitcoin-core-pr-reviews
23:36 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te60dxnaqz47amj.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Feb 10 00:00:55 2022