--- Log opened Wed Sep 01 00:00:54 2021
01:00 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
04:24 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has joined #bitcoin-core-pr-reviews
04:46 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
06:16 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
06:29 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
06:33 -!- koolazer [~koo@user/koolazer] has quit [Ping timeout: 250 seconds]
06:58 -!- emcy [~emcy@user/emcy] has joined #bitcoin-core-pr-reviews
08:05 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
08:14 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
08:15 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
08:20 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
08:20 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
08:31 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
09:18 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has joined #bitcoin-core-pr-reviews
09:25 -!- t-bast [~t-bast@user/t-bast] has joined #bitcoin-core-pr-reviews
09:28 -!- dopedsilicon [~dopedsili@103.159.243.27] has joined #bitcoin-core-pr-reviews
09:30 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:40 -!- dariusparvin [~dariuspar@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:47 -!- dariusparvin [~dariuspar@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
09:49 -!- Flexo82 [~Flexo82@0x3ec735a7.osd.customer.dk.telia.net] has joined #bitcoin-core-pr-reviews
09:51 -!- dopedsilicon [~dopedsili@103.159.243.27] has quit [Ping timeout: 252 seconds]
09:55 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:55 -!- dariusparvin [~dariuspar@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:56 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:58 -!- Flexo82 [~Flexo82@0x3ec735a7.osd.customer.dk.telia.net] has quit [Ping timeout: 244 seconds]
10:00 < glozow> #startmeeting
10:00 < larryruane> hi
10:00 < glozow> Welcome to PR Review Club!
10:01 < svav> Hi
10:01 < glozow> We're continuing the RBF theme this week, with #22675 extract RBF logic into policy/rbf
10:01 < schmidty> hi
10:01 < michaelfolkson> hi
10:01 < glozow> notes: https://bitcoincore.reviews/22675
10:01 < glozow> PR: https://github.com/bitcoin/bitcoin/pull/22675 
10:01 < merkle_noob[m]> Hello everyone.
10:01 < dunxen> hi!
10:01 < dariusparvin> hi!
10:01 -!- Kopekatona [~Kopekaton@563BB287.dsl.pool.telekom.hu] has joined #bitcoin-core-pr-reviews
10:01 < t-bast> hi everyone!
10:01 < glozow> Did anybody get a chance to review the PR? y/n
10:02 < glozow> or look at the notes?
10:02 -!- Azorcode [~Azorcode@190-36-255-2.dyn.dsl.cantv.net] has joined #bitcoin-core-pr-reviews
10:02 < glozow> does everybody have BIP125 memorized?
10:02 < dunxen> y-ish
10:02 -!- dopedsilicon [~dopedsili@103.159.243.27] has joined #bitcoin-core-pr-reviews
10:02 < Azorcode> Hello Everyone 
10:02 < dunxen> BIP125 not memorized sorry :(
10:02 < ccdle12> hihi
10:02 < michaelfolkson> yes to all questions, I can recite BIP 125 word for word by memory
10:02 < dopedsilicon> Hello
10:03 < glozow> We're basically going over BIP125 today. And you'll get extra credit for knowing some of the finer details :)
10:03 -!- Flexo82 [~Flexo82@0x3ec7379b.osd.customer.dk.telia.net] has joined #bitcoin-core-pr-reviews
10:03 < glozow> First question, since this is moveonly PR: What are some benefits of extracting the RBF logic into its own module?
10:04 < dunxen> we can reduce bloat in validation.cpp and test RBF stuff in isolation
10:04 < svav> de-bloating validation.cpp
10:04 < dopedsilicon> will prepare for future PRs
10:05 < svav> more modular code
10:05 < dariusparvin> Package RBF can use the same logic
10:05 < glozow> dunxen: svav: dopedsilicon: dariusparvin: yes! :)
10:05 < larryruane> this is allow unit tests (tests in isolation), but we don't have such tests now, do we? (just want to confirm)
10:05 < glozow> so many good things
10:05 < glozow> larryruane: correct, I believe the best way to test rbf logic is to run test/functional/feature_rbf.py right now
10:06 < glozow> we also have a fuzzer src/test/fuzz/rbf.cpp which tests the `SignalsOptInRBF` function
10:06 < dunxen> i also learnt about witness replacement today!
10:06 < glozow> dunxen: yay! wanna tell us what it is? :)
10:06 -!- Kopekatona [~Kopekaton@563BB287.dsl.pool.telekom.hu] has quit [Quit: Connection closed]
10:06 < glozow> (or larryruane?)
10:07 < dunxen> replacing same-txid-different-wtxid when the witness is smaller because higher fee rate? can do that in a BIP125 like way right?
10:07 < glozow> Okie anyway, we can also continue with the questions
10:07 < glozow> Why is the error returned here a TxValidationResult::TX_CONSENSUS instead of TxValidationResult::TX_POLICY, given that this is RBF-related logic?https://github.com/bitcoin/bitcoin/blob/0ed5ad1023d9ced8cb0930747539c78edd523dc8/src/validation.cpp#L774
10:08 < glozow> dunxen: yep!
10:08 < larryruane> yes I think it's that currently, if we get a tx that is the same as one already in our mempool except that its witness is different, we currently reject it, but we should accept it if its witness is smaller (higher fee rate), at least by a certain margin
10:09 < glozow> larryruane: right exactly
10:09 < larryruane> and what is "nice" about that type of replacement is that we don't have to evict any ancestors or decendents, since the replacement tx must specify exactly the same of those
10:10 < larryruane> so in a way it's a simpler replacement
10:10 < michaelfolkson> Cos we are talking about a potentially invalid transaction (consensus not policy)
10:10 < dunxen> for it being a consensus error, i'm not sure about it in depth, but isn't it basically checking for a tx that spends outputs that would be replaced by it. seems like consensus issue
10:11 < larryruane> glozow: ".. CONSENSUS .." because if the replacement were to happen (let's say B replaces A), then B couldn't possibly be valid, since one of its inputs is one of B's outputs!
10:11 -!- Blue_Moon [~Blue_Moon@189.132.182.94] has joined #bitcoin-core-pr-reviews
10:11 < larryruane> sorry meant one of A's outputs
10:11 < glozow> dunxen: larryruane: yes exactly. this is a consensus error because this transaction must be inconsistent if it's dependencies and conflicts intersect
10:11 < glozow> its*
10:12 < glozow> next question: why is it important for the replacement transaction to not introduce any new unconfirmed inputs?
10:12 < larryruane> i couldn't figure this one out!
10:12 < glozow> This is BIP125 Rule #2, described here: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details
10:13 < larryruane> maybe introduces some kind of DoS vector?
10:13 < dunxen> i was actually trying to think of an attack for this one
10:13 < glozow> larryruane: not DoS vector, no
10:13 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:13 < glozow> hint: https://github.com/bitcoin/bitcoin/blob/7e75400bb568fe8a653246c4e76f6baab2455a61/src/validation.cpp#L842-L851
10:14 < dunxen> Might we be able to invalidate another unconfirmed transaction that didn't opt into RBF?
10:14 < glozow> this restriction is more to make our RBF logic easier rather than prevent attacks, I think
10:15 < dunxen> oh cool checking the link
10:15 < t-bast> If I'm side-tracking, you can answer later: will we have a way to get rid of this rule for package-RBF? It's an annoying pinning vector and needed the special carve-out rule to be added, which is somewhat hackish...
10:15 < larryruane> ok sounds like in the future, we may allow this (which we can do because it's policy not consensus)
10:16 < glozow> t-bast: ah interesting, yes we can get rid of it, though I wasn't planning to.
10:17 < glozow> I agree it would improve RBF
10:17 < glozow> t-bast: to clarify, do you mean the CPFP carve out rule, https://github.com/bitcoin/bitcoin/pull/15681 ?
10:17 < t-bast> glozow: we should double-check with BlueMatt, but I think it would be nice to get rid of it, it made anchor outputs useless for lightning until Matt added the carve-out exception...
10:18 < t-bast> yes exactly, CPFP carve-out rule
10:18 < dunxen> does it simplify things since we don't need to check fee rate of the new tx corresponding to the new input which might be low fee rate?
10:19 < larryruane> going back to question 3 for a second, this really helped me understand why it's a consensus failure https://github.com/glozow/bitcoin/blob/2021-08-rbf/test/functional/feature_rbf.py#L324
10:20 < glozow> dunxen: yes! :) you can imagine that, if the new replacement transaction adds higher fees, but has a low ancestor fee, it's not actually going to be a better candidate for miners
10:20 < dunxen> larryruane: thanks for the test link!
10:21 < glozow> so let's say we're replacing mempool tx, A, with a new tx, B
10:21 < glozow> A is 3 sat/vb and B is 5 sat/vb
10:21 < glozow> but B has an unconfirmed input, another transaction in the mempool with 1 sat/vb
10:22 < glozow> this isn't an "attack" but it's a case we want to consider when we're deciding whether or not a new transaction is a better candidate for mining
10:22 < glozow> hopefully this makes sense?
10:22 < dunxen> clears it up a lot, thanks!
10:22 < glozow> great!
10:23 < glozow> next question: The code in `PaysMoreThanConflicts()` doesn’t seem to directly correspond to a rule in BIP125. Why do we have it, and why don’t we merge it with the other fee-related checks in `PaysForRBF()`?
10:23 < glozow> `PaysMoreThanConflicts()`: https://github.com/bitcoin/bitcoin/blob/a33fdd0b981965982754b39586eedb7ae456ba57/src/policy/rbf.h#L76
10:23 < glozow> `PaysForRBF()`: https://github.com/bitcoin/bitcoin/blob/a33fdd0b981965982754b39586eedb7ae456ba57/src/policy/rbf.h#L88
10:23 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews
10:24 < larryruane> as a higher-level point then, we're trying to run our mempool management as if we're a miner (like, what would a miner think is good), really (i think?) so that we can *forward* transactions appropriately ... but miners could act differently than we expect! E.g. a miner *could* replace that tx (that has a new unconfirmed input)
10:25 < dunxen> i guess in this case anti-DoS can be argued somewhat? also want to make sure there is incentive for a miner to use the new one?
10:25 < larryruane> (i hope that's right, a question, not an assertion!)
10:26 < glozow> larryruane: yes, I consider this to be one of the main goals of mempool - to keep the most incentive-compatible transaction candidates for mining, even if we're not a miner
10:26 < glozow> dunxen: why anti-DoS?
10:27 < sipa> there is a fundamental conflict between DoS protection (e.g. not allowing people to use the P2P network to broadcast transactions that will never confirm), and miner incentives (maximizing joint fee of the top 1 block worth of the mempool)... our goal so far is minimizing / specifying where that conflict occurs, but to an extent, it's inevitble
10:28 < glozow> sipa: right. if we had infinite resources, we would only need to apply consensus rules
10:28 < dunxen> i'd think it's expensive to replace transactions, so the cost should be higher fee rate each time you want to do that right?
10:29 < sipa> i guess there is an additional one: our mempool is also _our_ prediction of what will confirm, and in theory, miners could keep mempools with e.g. conflicting transactions around, and pick the best combination at the time of mining
10:29 < sipa> but that's incompatible with us trying to guess what will happen
10:30 < michaelfolkson> sipa: And BlueMatt said the other day Lightning wants the most relaxed mempool policies possible (partly in jest perhaps). So that is another factor in the conflict
10:30 < sipa> michaelfolkson: well, everything wants them to be as relaxed as possible
10:30 < sipa> the world would be a lot simpler :p
10:30 < michaelfolkson> Ha
10:30 < sipa> but that's not DoS friendly
10:31 < glozow> dunxen: yes! the best way to avoid expensive operations is to disallow replacing transactions, but we also want to allow replacements so that we can get better-fee transactions. so this is a happy middle
10:31 < sipa> it's particularly worrisome for Lightning and perhaps other 2nd layer protocols, as their correctness relies on being able to predict what will confirm, which is... eh
10:31 < larryruane> there's been that dust limit discussion lately on the mailing list, maybe that's another instance of this, sort of
10:31 < sipa> larryruane: yes, though hopefully one that's moot in scenarios where fees are high enough
10:32 < sipa> (as fees will make everything that's remotely classifiable as dust also actually uneconomical, so nobody will create it)
10:33 < glozow> i feel like dust doesn't fall into the buckets of anti-DoS and useful mempool, but into a 3rd category of "(non-consensus) rules we think are good for the network to follow"
10:34 < larryruane> glozow: interesting! makes sense
10:35 < glozow> anyway, I'll answer the last question: `PaysMoreThanConflicts()` is an early-exit thing. We haven't gone digging in the mempool for descendants-of-conflicts yet, but we can compare fees with the direct conflicts because we'd be able to exit immediately if we're not paying more than them. 
10:35 < michaelfolkson> A big mempool and the prediction element isn't important. A small mempool and then we're potentially talking retrieving transactions we don't have in our mempool to validate a block (not ideal)
10:36 < glozow> in `PaysMoreThanConflicts()`, we're making sure the replacement transaction fees >= direct conflicts fees. if it's not better, we can quit immediately. anybody have an idea why?
10:36 < glozow> if it is better, we'll also make sure that the replacement tx fees >= conflicts + descendants fees.
10:37 < glozow> ^why do we need to do that?
10:37 < sipa> glozow: well i'd consider dust accumulation in the mempool and p2p bandwidth/validation cost both DoS concerns, though very different ones admittedly
10:37 < larryruane> glozow: so it's just performance .. would be great to add a comment to `PaysMoreThanConflicts()` to explain that
10:38 < glozow> sipa: in mempool, if the tx ends up confirmed, then I'd consider it a good use of resources right?
10:39 < glozow> larryruane: comment is here https://github.com/bitcoin/bitcoin/pull/22855/files#diff-fa5cb2d84034ff72cdb9d479b17cf8c744a9bf3fc932b3a77c1a017edd767dfaR132-R141
10:39 < glozow> wait sorry no, this is the comment: https://github.com/bitcoin/bitcoin/pull/22855/files#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R785-R790
10:40 < glozow> (btw, if you think RBF is confusing and want more docs, #22855 would be good to review :P)
10:41 < glozow> I'm going to continue with the notes, but feel free to ask questions about past stuff
10:41 < glozow> In BIP125 Rule #4, what does it mean for a transaction to “pay for its own bandwidth?” Why don’t we just allow any replacement as long as it has a higher feerate?
10:42 < michaelfolkson> I think BIP 125 needs some footnotes explaining the rationale for the rules too
10:42 < michaelfolkson> We hounded ariard to explain their rationale at the Sydney Socratic. Perhaps they were explained in an old mailing list post.... https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/#bip-125-rules-and-their-rationale
10:42 < michaelfolkson> I don't think they are in the code comments
10:43 < dariusparvin> paying for its own bandwidth means paying a fee which includes an additional amount that would cover its minimum relay fee?
10:44 < dariusparvin> *the node's minimum relay fee
10:44 < larryruane> dariusparvin: I think you're right -- we already relayed the original tx(es) and if we accept the replacement, we have to replay it too (?)
10:46 < glozow> dariusparvin: larryruane: yep. we'll be relaying the transaction. and we already relayed the original one(s). so it needs to pay for that second relay
10:46 < dariusparvin> i guess having rule #4 rather than just #3 is also a kind of DoS protection? So that the sender doesn't keep incrementing the replacement tx by 1 sat
10:46 < larryruane> so in effect the new tx has to pay for the old tx's relay (which was in a sense an unnecessary relay (of the old one))
10:46 < glozow> what would happen if we allowed any replacement as long as it pays more fees?
10:46 < glozow> dariusparvin: indeed, this is definitely a DoS protection
10:46 < larryruane> glozow: bump by one sat each replacement?
10:46 < dunxen> we could just change the fees by 1 sat if it didn't pay for its own bandwidth right? that would mean we could replace a lot pretty cheaply and DoS?
10:47 < glozow> larryruane: dunxen: yes! and we'll be spamming the network with transactions
10:47 < dopedsilicon> One can keep increasing the fees by insignifacnt amounts
10:47 < dunxen> yes that too haha
10:47 < glozow> and if everyone else is also accepting them, they'll also be flooding the transactions
10:48 < dunxen> oh that would be kinda bad
10:48 < glozow> pretty gross abuse of mempool resources and network bandwidth
10:49 < glozow> so here's a nice tradeoff between protecting mempool resources + wanting higher fee transactions :)
10:49 < glozow> next question: In BIP125 Rule #5, how is it possible for a transaction to conflict with more than 100 mempool transactions, given that mempool ancestor and descendant limits don’t allow a chain of more than 25 transactions?
10:50 < dunxen> could it be like a wide tree of descendants?
10:50 < larryruane> is it because the new tx could have (say) 110 inputs, all of which are the outputs of separate mempool transactions?
10:50 < glozow> larryruane: ding ding ding
10:50 < glozow> it can conflict with a bunch of independent transactions in the mempool, yep
10:51 < glozow> dunxen: wide tree of descendants would still be counted together
10:51 < dunxen> oh got it, so like independent ancestors would not?
10:52 < glozow> dunxen: yeah, they're not connected, so they won't hit the ancestor/descendant limits
10:52 < glozow> next question. here's the signature for `PaysForRBF()`: https://github.com/bitcoin/bitcoin/blob/a33fdd0b981965982754b39586eedb7ae456ba57/src/policy/rbf.h#L88
10:52 < glozow> why is `hash` passed by reference but `original_fees` by value? Should the fee parameters be const? Why or why not?
10:54 < larryruane> i think reference versus non-reference is often (not always!) a performance consideration.. we don't want to pass a 32-byte thing on the stack (copy), but a `CAmount` is just 8 bytes, usually the same size as a pointer (which is what a reference really is)
10:54 < larryruane> so passing a CAmount by reference is passing the same amount of data (8 bytes), but is slower to access (memory lookup)
10:55 < glozow> larryruane: yes! we often want to pass by reference because (1) we want to mutate it in the function or (2) the size of the reference is smaller than the object itself, e.g. `CAmount`
10:56 < larryruane> it's kinda too bad which of those two reasons is operative isn't obvious from reading the function prototype!
10:56 < glozow> and what about the other part of the question - should it be const? why or why not?
10:57 < glozow> `original_fees`, `replacement_fees`, and `replacement_vsize`
10:57 < larryruane> specifying a pass-by-value (as in this case with the CAmount) as a `const` in the prototype actually is always wrong, because the caller doesn't care whether the called functions changes the variable *internally*
10:57 < larryruane> (or shouldn't)
10:57 < glozow> right, what's the scope of `original_fees`?
10:58 < larryruane> but in the definition of the function, `const` can make sense
10:58 < larryruane> glozow: do you mean in the calling function or the called function?
10:59 < glozow> larryruane: the callee. or both, if you want to elaborate :)
10:59 < larryruane> in pass-by-value, the called function gets a copy, and the scope of that copy is only within that called function (out of scope when the function returns)
11:00 < glozow> larryruane: yep!
11:00 < larryruane> in the calling function, the scope is before and after the call
11:00 < glozow> and even if the callee mutates it, it's a copy, so it doesn't matter to the caller
11:00 < glozow> looks like we have run out of time. thanks for diving into RBF with me today, everyone! hope it was fun
11:00 < glozow> #endmeeting
11:01 < larryruane> thanks glozow this was great, learned a lot!
11:01 < dariusparvin> thanks a lot glozow! fun and informative as always
11:01 < svav> Thanks glozow
11:01 < dunxen> thank you! policy stuff is always interesting!
11:01 < glozow> next week is wallet coin selection PR: https://bitcoincore.reviews/22009
11:01 < dopedsilicon> thank you!
11:01 < glozow> (just got merged this morning)
11:02 < larryruane> dunxen: yes, in a way it's more interesting, in that you can innovate in policy areas! (more so than consensus)
11:02 < glozow> i also love policy :D fun tradeoffs
11:02 < dariusparvin> Something it made me wonder. It seems like it's important that the mempool policies dont become too restrictive, otherwise users might be incentivized to go directly to miners who dont implement any of these policies?
11:02 < merkle_noob[m]> Thanks glozow and everyone who participated. I feel like my brain has expanded a little...
11:03 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:03 < glozow> dariusparvin: I think they implement policy, but I agree that the resources they'd be wiling to expend on transaction candidates is far greater than what we can reasonably expect the typical user to allocate for their everyday node
11:04 < glozow> so they'll probably have bigger mempools, for example,
11:04 < glozow> and maybe a lower minimum fee
11:04 < michaelfolkson> Thanks glozow. The scripted diff commit might need to be updated for next week. I think John normally saves the commit in the review club repo rather than linking to the Core repo for commits
11:04 < dariusparvin> right, yeah
11:04 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has quit [Quit: Leaving...]
11:05 < michaelfolkson> But if it has been merged just needs an updated link
11:06 < dariusparvin> glozow a miner would also probably be willing to treat every tx as signaling RBF, just in case
11:08 < t-bast> thanks glozow, really appreciate it!
11:08 -!- dopedsilicon [~dopedsili@103.159.243.27] has quit [Ping timeout: 252 seconds]
11:09 -!- Azorcode [~Azorcode@190-36-255-2.dyn.dsl.cantv.net] has quit [Quit: Connection closed]
11:09 < larryruane> hey what might be really interesting to do (maybe someone has done this already) is, when our node receives a new block, compare its transactions with what we THINK would be in that block, and somehow generate some kind of report on where they are different ... (of course some diffs could be due to just timing)
11:10 < larryruane> it would be interesting to see if *miners* are running different policies than us (or, as dariusparvin said, tx submitters are going out-of-band to miners)
11:11 < glozow> larryruane: the rebroadcast PR implements something very similar to what you're describing, but it generates a block every minute or so instead of upon receiving a block https://bitcoincore.reviews/21061
11:11 < larryruane> 👍
11:11 < glozow> i would imagine the biggest difference is miners prioritising their own transactions
11:12 < glozow> not sure though, don't know much about mining
11:12 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
11:13 < glozow> if i were a miner, i'd just set my mempool to be really big
11:14 < larryruane> yeah for max fees ... "... their own transactions ..." hmm interesting, I'd think miners usually send their coinbase to an exchange (so they can sell for their local fiat currency to pay for electricity), so would they have a preference to do that in a block they themselves mine, i wonder? 
11:15 < glozow> larryruane: I'd imagine so. don't have to pay fees in your own block
11:15 < larryruane> at first i thought yes, because they save the fees! but that's also an opportunity cost -- they could fill the block with other tx's (that obviously pay fees too)
11:16 < larryruane> it's not obvious to me that they're better off mining their own tx, but i may be missing something
11:16 < dariusparvin> even if a miner did pay normal fees, it would receive them back, so it wouldn't make a difference would it? just as long as they didn't broadcast that tx to other miners and end up paying them
11:17 < larryruane> it's interesting, we make these mempool and relay policy changes, but we don't really have a good way to get feedback or ideas from miners, do we? maybe informally?
11:19 < glozow> 🤷
11:21 < larryruane> dariusparvin: yes.. I'm just wondering if there's any downside to them just broadcasting the tx the same as everyone else does .. because, again, if they mine their own transaction, and *if* blocks are full, then they would *not* be able to include the lowest paying transaction(s) that they would otherwise include
11:22 < larryruane> i guess if blocks aren't full, then they're better off mining it themselves
11:22 < larryruane> (because it's essentially free to them)
11:24 < dariusparvin> larryruane yeah that makes actually. If blocks are full then they are either going to pay another miner, or pay the opportunity cost of not mining someone else's tx. So it's only really free for them if the blocks are not full 
11:27 < larryruane> yes.. mining is pretty mysterious, probably because it's so competitive! (like with that ASIC-boost craziness a few years ago!)
11:44 -!- dariusparvin [~dariuspar@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
11:45 < harding> Oh, drat, t-bast left.  I didn't really understand his comment about BIP125#2 making RBF useless for LN before CPFP carve out.  I think the main motivation for carve out from LN is BIP125#3, which is that if we have a transaction with an input co-owned by Bob and Mallory which each of them can RBF, Mallory can replace that with a 100,000 vbyte version that pays a low feerate (say 1 sat/vbyte = 100,000 sat = $50 USD now) and now Bob can 
11:45 < harding> only replace that tx with the (say) 1,000 vbyte tx he really wants by paying at least 101,000 sat in fees, which could be more than the channel is worth to Bob.  AFAIK, this has nothing to do with allowing or disallowing unconfirmed inputs in a BIP125 RBF.
11:47 < harding> (That was an enjoyable meeting log to read, thank y'all for participating!)
11:50 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
12:15 -!- Blue_Moon [~Blue_Moon@189.132.182.94] has quit [Quit: Connection closed]
12:17 -!- Flexo82 [~Flexo82@0x3ec7379b.osd.customer.dk.telia.net] has quit [Quit: Connection closed]
12:21 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:15 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
13:15 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #bitcoin-core-pr-reviews
13:26 -!- dongcarl [~dongcarl@96.224.58.144] has quit [Ping timeout: 248 seconds]
14:11 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has quit [Quit: Connection closed]
15:06 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
17:18 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:30 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
18:21 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity]
--- Log closed Thu Sep 02 00:00:57 2021