l2-onchain-support-meeting2.txt

19:01 -!- suredbits is now known as Chris_Stewart_5
19:01 < darosior> hi
19:02 <@ariard> will try to do a different meeting format, like sharing the question and give time to everyone to share their thoughts?
19:02 < glozow> sounds good!
19:02 < t-bast> sgtm
19:03 < harding> +1
19:03 <@ariard> what problem(s) package-relay aim to solve at the base-layer :) ?
19:03 <@ariard> (feel free to take the mic!)
19:04 < rgrant> hi
19:04 < michaelfolkson> A CPFP transaction not making into a block speedily to make sure a justice transaction gets confirmed
19:04 < glozow> i see package relay as a way of correcting current limitations wrt evaluating transactions as candidates for mempool. namely, that we want the best transactions in our mempool, but we aren't always able to see their true feerate by looking at them one at a time
19:04 < t-bast> A simple problem that comes to mind is allowing the recipient of a tx to fee bump that tx without the sender having to do anything, in all cases (initial tx fee below mempool min fee)
19:05 < darosior> Avoid rejecting a set of transactions from your mempool that could be included in a block by a rationale miner
19:05 < glozow> (best being, what miners want)
19:05 < t-bast> I like darosior's way of putting it
19:05 < Chris_Stewart_5> When you want a utxo to have a series of state transitions to happen atomically
19:06 < harding> Chris_Stewart_5: hmm, I don't actually like that definition.  I don't think package relay can help with that.
19:06 < harding> I.e., it's always possible for the parent to be confirmed without the child even if that's not fee-rational.
19:06 < rgrant> i would define package relay as small hints for what's otherwise a hard-to-compute problem.
19:07 < Chris_Stewart_5> from an application developer perspective, that is what i want
19:07 <@ariard> to me, i think package-relay can help to propagate branch of transactions with a low-feerate root
19:07 < Chris_Stewart_5> if this isn't for app devs, then ignore me :-)
19:07 < harding> Chris_Stewart_5: oh, sure, atomicity guarantees are always a nice thing to have; I just don't think it's possible for package relay to provide that.
19:07 <@ariard> rgrant: can you explain more :) ?
19:08 < michaelfolkson> Chris_Stewart_5: What is an example of the state transitions? A UTXO is either locked/unlocked or unspent/spent?
19:08 < Chris_Stewart_5> michaelfolkson: funding tx -> commitment tx -> htlc txs is an example IMO. In DLC world, funding tx -> CET (contract execution tx)
19:09 < michaelfolkson> Oh ok, so chains of transactions basically
19:09 < glozow> Chris_Stewart_5: I'm here because I want to hear what devs building on top of bitcoin core want from package relay
19:09 < harding> Chris_Stewart_5: it certainly is for application developers; I just don't know how to achieve what I think you want.
19:09 < t-bast> Chris_Stewart_5: but do you mean that you'd want the whole chain of txs to be confirmed in the same block?
19:09 < rgrant> ariard: first, i too like darosior's definition, but in addition to that package relay is a way for someone to suggest a set that algorithms would otherwise need to be searching for.
19:09 < Chris_Stewart_5> I think my definition might be a little incorrect, but hopefully it gets the point across
19:10 < harding> At least symettrically; you can guarantee a parent is confirmed before a child but not the other way around.
19:11 < Chris_Stewart_5> Well i think at minimum accepted into the mempool A block would be even better 
19:11 <@ariard> rgrant: hmmm do you mean block assemblage algorithms?
19:12 < glozow> perhaps a guarantee that package relay could provide is that your transactions get propagated as intended, so you're not stuck with a wrong execution path because you couldn't get your tx to a miner in time
19:12 < t-bast> I think that batching confirmation in the same block isn't a job for package relay, but ensuring it makes sense to relay them together to other mempools should be
19:12 < harding> t-bast: agreed.
19:13 < rgrant> can someone link me to glozow's appropriate branch or pull request?
19:13 < glozow> rgrant: I agree in the sense that, after nodes are able to do package validation, package relay serves as a hint of "hey, u should run these transactions through package validation rather than individual tx validation"
19:13 < Chris_Stewart_5> glozow: Yeah, i think the worst case is my commitment tx makes it into the mempool, but my htlc txs can't for some reason. That means my "package" isn't getting relayed IMO. 
19:13 <@ariard> t-bast: i think the makes sense notion is interesting, because it might differ in function of the receiver's mempool you're considering
19:13 < glozow> rgrant: i have a list here https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add#1-package-validation-and-package-specific-policies
19:14 <@ariard> like should you assemble package based on mempool min feerate or should you assemble package based on sender-defined feerate?
19:14 < glozow> Chris_Stewart_5: that makes sense
19:15 < t-bast> ariard: I agree, it's quite hand-wavy because we have to accept that the network is heterogeneous and we can't have a rule that will make sense for everybody
19:15 < michaelfolkson> Chris_Stewart_5: And in DLC world you want the funding tx and CET in the same block?
19:15 < rgrant> ariard: i do see package relay and block assemblage as related, but i can see how just paying to send messages through the flood network might not always rely on acceptance in a block.
19:16 < Chris_Stewart_5> michaelfolkson: No, that was a bad example on my part. Perhaps a fee bumping spend from the CET though. I think lightning makes more sense with these analogies because there is 3 layers of tx. Funding, commitement, and htlc/penalty txs
19:16 < rgrant> ariard: if there's any chance for message not expected to land in blocks to go through, that could burden the network (and LN would be able to handle it better)
19:17 < michaelfolkson> Chris_Stewart_5: Ok thanks, makes sense
19:18 <@ariard> t-bast: sure i meant more as a local node mechanism, what could be the different triggers of a package generation? e.g you have transaction A of which the feerate doesn't pass Alice's `feefilter`, and you have multiple childs of A present in your mempool
19:18 < glozow> Chris_Stewart_5: so in that use case, a 2-transaction package would work?
19:19 < glozow> to CPFP fee-bump the CET?
19:20 < michaelfolkson> glozow Chris_Stewart_5: With DLCs there are lots of alternative transactions but only only one can get confirmed (afaiu). So yeah a 2 transaction package with the "winning" transaction and the CPFP
19:20 < Chris_Stewart_5> glozow: Yes. We have built in refund transactions for the case that an oracle disappears. If you do not get your CET confirmed before this refund tx, you could possibly lose funds.
19:20 < t-bast> glozow: reading through your link, I think LN would have enough flexibility with `Two generations only, with 1 or more sponsored parents + 1 sponsoring child`, and could get away with `Simply 1 parent + 1 child` if we forget about batching (and accept being a little less fee efficient)
19:21 <@ariard> rgrant: though "not expected to land in blocks" is relative of your mempool top feerate, should you relay low-feerate transaction still higher than your peers's mempool min feerate?
19:21 < rgrant> do we have simple rules yet like "if packages cause eviction of some number of bytes from the mempool, then the average feerate of the bytes added must be higher than te average feerate of the bytes evicted?
19:21 < t-bast> ariard: I didn't realize you were asking about the node logic to build packages when relaying, I was just thinking as a higher layer user of that feature
19:21 < glozow> t-bast: awesome! 😍
19:22 < Chris_Stewart_5> glozow: thanks for the link, will read through later
19:22 < harding> Chris_Stewart_5: out of curiousity, how tight are the typical bounds on the refund?  LN has been setting very tight bounds (e.g. 40 blocks or less) to prevent attacks where funds can be locked up for long amounts of time.  I think DLCs can probably use much loose bounds (e.g. 1000s of blocks maybe) and so would be fundamentally much less vulnerable to feerate management problems and pinning attacks.
19:22 <@ariard> rgrant: yes that's already how LimitMempoolSize works iirc
19:22 < darosior> glozow: don't want to derail the meeting but have you thought about a package-based CBlockPolicyEstimator? If CPFP is used a lot it seems to me that it could bias the estimation. Hmm i'd have to think more about it.
19:23 < t-bast> glozow: does `Two generations only, with 1 or more sponsored parents + 1 sponsoring child` create more technical problems than `Simply 1 parent + 1 child` for you? Or do they have the same drawbacks for layer 1 (with slightly more implementation complexity)?
19:23 < glozow> darosior: i must admit i haven't thought about it - I hardly knew `CBlockPolicyEstimator` existed until very recently 😅 
19:23 < michaelfolkson> And you could have an alternative competing package if the initial CPFP wasn't effective? A CPFP package that RBFs the previous (too low fee) CPFP package?
19:23 < darosior> ok :) i'll look into it, maybe smarter people actually solved this years ago as often!
19:24 < rgrant> ariard: then relay rules should be aligned well enough with block acceptance rules that you should relay a fairly-low feerate transaction that is higher than your peer's min feerate.
19:24 <@ariard> t-bast: so as a higher-layer user you can broadcast A then high-feerate B, but in your mempool you might already have A and another child C, with a lower-feerate
19:25 < glozow> t-bast: 2 gen multi parent single child is a significant simplification, actually. it is slightly more complex than parent+child but still makes me very happy to hear
19:25 < Chris_Stewart_5> harding: the refund is user configurable. We haven't really decided on what best policy is yet. But i think your analysis is probably correct. We have a new type of DLCs in pipeline called "disjoint union" DLCs where you can have logic like "liqudiation thr
eshold breached where i liquidate collateral at $30,000" OR a certain time threshold is met. This opens the question of what happens
19:25 < Chris_Stewart_5> when the liquidation threshold is reached slightly before the time threshold. I haven't thought too deeply about this in the package relay context
19:25 <@ariard> and if you package-relay the pair {A,C}, which might be higher than your peers's mempool min feerate it can still downgrades its odds of confirmation?
19:25 -!- murchandamus is now known as murch
19:26 < t-bast> ariard: for LN it's not an issue because you usually are the only one to be able to broadcast A, so people couldn't sneak in C before B if you put them as a package `A + B`
19:26 < harding> Chris_Stewart_5: does the oracle do the timekeeping or do you use MTP?
19:26 < t-bast> ariard: (A being a commit tx or htlc tx)
19:26 < Chris_Stewart_5> harding: they can be two separate oracles, attesting to independent events and completely unaware of each other. The DLC is built custom client side.
19:26 <@ariard> michaelfolkson: yes you mean RBF-package in case of competing LN's commitment transactions
19:26 < t-bast> glozow: great, good to know!
19:27 < rgrant> glozow: thanks for the link, very helpful!  i don't understand why we can't support RBF in packages.  is that an implementation limitation or a policy limitation?
19:27 < t-bast> ariard: but someone else could relay `A+C` once you've broadcast `A+B`, you're right, but in that case RBF rule to get B to replace C should save us, doesn't it?
19:27 <@ariard> rgrant: ah might question was more oriented if it would make sense to not broadcast your whole mempool content to save on bandwidth, but that's quite a side-topic
19:28 < glozow> rgrant: it's a simplification that makes package validation easier to implement and reason about
19:28 < harding> Chris_Stewart_5: ok.  To me, as long as the timekeeping is being done by an oracle, then I think your only concern related to package acceptance is still related to the refund condition, and I think that's a case where DLCs are in a much healthier position than current LN.
19:28 < Chris_Stewart_5> harding: in general, oracles are blockchain agnostic. The same oracle for DLCs works on zcash, litecoin, bitcoin, bcash etc. No network specific configurations oracle side
19:28 < glozow> is BIP125 RBF for packages something that we want?
19:29 < Chris_Stewart_5> probably ETH lol
19:29 < michaelfolkson> rgrant: There are lots of DoS vectors that Suhas, glozow, ariard have to wrestle with when trying to implement this
19:29 <@ariard> t-bast: you broadcast A+B at first time, your peer broadcast C spending A's remote anchor output then you fee-bump/rebroadcast with A+D, i think it can happen?
19:29 < t-bast> glozow: it depends, in a `parents + single child` package I think we do need to be able to replace the child with RBF (but not the parents)
19:30 < t-bast> ariard: I'm hoping this scenario can happen too! :)
19:30 < harding> glozow: I think some type of replacement for packages will be important in the long run.  Otherwise, even in the best case, you're limited to (n-1)/x feebumps where n is the descendent limit and x is the number of parties in a protocol who can fee bump a commitment or whatever transaction.
19:31 <@ariard> glozow: yeap i think so otherwise your counterparty might have a low-feerate package already in the mempool?
19:31 < darosior> glozow: if we limit the size to 2, we can just RBF the child the non-package way?
19:31 < glozow> t-bast: i think that's perfectly doable now if you've got the package in, and the child doesn't already have descendants in the mempool
19:31 <@ariard> t-bast: yes but now you're back to the issue of your mempool assemblage logic potentially lured to relay a lower-feerate package than the one expected?
19:32 < t-bast> glozow: and if the child has descendants, can we rely on the current BIP125 rule to still replace it or does it add new issues?
19:32 < harding> I take back what I just said, I think darosior has it right.
19:32 <@ariard> darosior: right, but your expected parent might have been evicted in between, and we can assume you don't have global view of the mempool?
19:33 < glozow> t-bast: darosior: yeah, it's just a BIP125 RBF of the child.
19:33 < harding> ariard: oh, good point.
19:34 < t-bast> ariard: I see what you mean, I hadn't thought about that. If packages are small (two generations) is it really an issue though?
19:35 < harding> ariard: what I understand you to be saying is that commitment tx A is currently in the mempool along with anchor spend B giving it fees.  You want to increase the fees by creating B' but, in the meantime, A has been replaced by A'.
19:35 < glozow> can you make a child for A' or no?
19:36 <@ariard> t-bast: well your counterparty can downgrade the feerate of your expected package? so maybe the package assemblage logic should just search for the best feerate subset among your in-mempool chain of transactions?
19:36 < darosior> ariard: wait but eviction would be based on the entire package? If you need to RBF, RBF the child. If it so happens that the package was evicted re-broadcast the entire package. I don't see how it differs from current behaviour
19:36 < harding> glozow: yes, but you don't know about A'.
19:36 < t-bast> glozow: in the case of LN yes, we can, so it may save us
19:36 <@ariard> harding: yes exactly
19:36 < t-bast> but as harding says, we can't know if it's a revoked commit tx (and we may have thousands of versions of the tx, so can't blindly try them all)
19:36 < harding> glozow: so if you relay A->B', your fee bump works, but if you just relay B' it can't bind to A.
19:37 < t-bast> ariard: I think that would make sense (searching for the best feerate subset)
19:37 < glozow> ah so you might want to submit B' as a single transaction to get the RBF, but you want to relay {A, B'} together to tell peers to validate them as a package
19:37 < darosior> ok got it.
19:37 <@ariard> darosior: sure you can re-broadcast the entire package though you need a replacement rule for this one to replace an-already in-mempool chain of transactions?
19:38 < harding> That's kind of a nasty problem, though, because it requires relay nodes to relay {A,B'} as a package even through nodes that already know about A.
19:38 <@ariard> harding: yep bad for bandwidth :/
19:38 < glozow> right, i think we should trim packages when we already know about a transaction in it
19:38 < darosior> Yes. It might be a pretty limiting factor if we ever want to increasing package size
19:38 < glozow> also i don't think we should relay entire transactions when talking about packages on p2p
19:39 < t-bast> glozow: but you don't know if your peer knows about it, so you may need to relay as a package to your peers, don't you?
19:39 < harding> ariard: is this related to your criticism on https://github.com/bitcoin/bitcoin/pull/22252 ?  I was having trouble understanding your concern from a quick skim, but this makes sense to me.
19:40 < t-bast> I'd see that as an argument for `single parent + single child` instead of `multiple parents + single child`, to limit bandwidth waste
19:40 < glozow> i have perhaps a different view of package relay? I think all you need to do is communicate hints about when to use package validation. so I'm thinking you don't need to relay the transactions themselves, just the wtxids of transactions you think should be package validated. and tx relay still happens the normal way
19:40 <@ariard> t-bast: well we track per-peer announced txids in `filterInventoryKnown`
19:40 <@ariard> assuming you rely on the INV announcement mechanism
19:41 < rgrant> glozow: that's my intuition as well
19:41 < glozow> like, package relay is less about communicating transactions, and more about communicating how to validate them
19:41 < t-bast> ariard: but you can't know if the tx has been evicted since your peer last announced it had it?
19:42 <@ariard> harding: yes your counterparty might have a same-txid-different-txid lower-feerate proposal already in the mempool?
19:42 < t-bast> glozow: in that case you'd send B + A's txid, and your peer can then ask you to send A if it doesn't have it to validate it as a package on its side?
19:42 < harding> glozow: how far away do your hints travel?  If they just go to your direct peer, then I think this problem exists where Alice wants to send {A, B'} to Bob who knows about {A, B} to miner Carol who knows about {A'}.  The hint to Bob doesn't help and Bob doesn't know to send a hint to Carol, so B' never gets to her for mining.
19:42 < glozow> t-bast: yeah. they can still request the transactions they need
19:43 < t-bast> glozow: at first glance, it makes sense to me and shouldn't be very wasteful in terms of bandwidth/latency
19:43 <@ariard> glozow: agree we can rely on TX messages, it's more the INV-GETDATA that might be updated?
19:45 <@ariard> t-bast: right, you're not aware of the replacement happening in your peer's mempool
19:45 < glozow> ariard: mm, right. I don't have a BIP proposal or anything, just don't think we should worry too much that bigger packages take up more bandwidth
19:45 < glozow> harding: oo hm, hadn't thought about that
19:45 < harding> glozow: me neither!  Hat tip to ariard!
19:45 < livestradamus> http://audiobookbay.nl/
19:45 < t-bast> And Carol doesn't even know that B's parent conflicts with A' if we only send A's txid at first
19:46 < livestradamus> Oops wrong window sorry for the link
19:46 <@ariard> livestradamus: you can stay if you're interested :p
19:47 < livestradamus> I'll catch up, it's night time here
19:47 < rgrant> harding: do we need to make some claim of "achievable average feerate of this package" when sending hints?  then Bob would say "i don't have a tx that achievesthat feerate, send B'".
19:48 < t-bast> I agree with rgrant, I think it makes sense to send a feerate hint so that your peer can decide whether it makes sense to fetch the rest of the package or not
19:48 < harding> rgrant: I don't think so, I think as long as we can hint that the package is over the peer's BIP133 minrelayfeerate, we're ok.
19:49 <@ariard> glozow: well i think the question of "does bigger package take more bandwidth is function of the package announcement mechanism ?" like if you say explicit package hints with the whole list of wtxids to atomically validate
19:49 < rgrant> harding: then why doesn't Bob ask for B'?  and why doesn't the miner build {A B'}?
19:49 < t-bast> actually maybe it doesn't solve what I think it solves since your peer doesn't even know whether your package conflicts with some of the txs in his mempool until he fetched the whole package...
19:49 < glozow> harding: so what we want is Bob to replace B with B', and then sends {A, B'} to Carol, who replaces A' with A, then does {A, B'} ?
19:50 < glozow> maybe when you get your package hint, first you try all of them as replacements, and then you package validate...
19:50 < harding> rgrant: Bob does ask for B', but when he tries sending it to Carol, she considers it an orphan.
19:50 < harding> glozow: correct.
19:50 < michaelfolkson> Full nodes don't calculate the average fee rate (satoshis per vbyte) in a block do they? Wallets typically get network fee rate stats from centralized APIs?
19:50 <@ariard> t-bast: i believe one downside of feerate-based announcement mechanism is you need to announce the utxo, so maybe you leak a bit of bandwidth hmmm?
19:51 < t-bast> but Bob could send A's txid as a hint? Is there a reason *not* to send it (unless your peer already said he had seen A)?
19:51 < t-bast> ariard: yes exactly, we'd need to send the utxo to check for conflicts, and it may be a rabbit hole if we follow that logic further...
19:52 < rgrant> harding: oh, i may be misunderstanding notation.  i assumed that Carol would evict A' from the block's consideration if {A B'} has high enough feerate.  what am i missing?  was A' already buried in a block?
19:52 < harding> t-bast: I guses the only reason not to send it is that we're possible talking about a massive increase in INV overhead here by announcing all the parents of every transaction with mempool ancestors.
19:53 < t-bast> harding: of course, but if we're limiting package to `1 parent + 1 child` is it still too much?
19:54 < t-bast> harding: it feels like whenever we'll try to be clever and omit the hint, there will be an edge case where propagation stops
19:54 < harding> t-bast: I don't know, I think that's the kind of thing that would need to be backtested against typical mempool contents, and we'd want to talk to gleb about how that would affect erlay's assumptions.
19:54 < glozow> so what we might want is 1 parent + 1 child, with RBF enabled?
19:55 < rgrant> what if packages are never retouched by nodes along the flood network?  what if they live or die as they were initially injected?
19:55 < harding> rgrant: sorry, it is an awful ad hoc notation.
19:56 <@ariard> michaelfolkson: you mean something as per-block feerate ? nope i can't remember doing that though block feerate information is consumed by the fee estimator
19:56 < t-bast> I think that 1 parent + 1 child, with RBF enabled at the package level (I can send `A + B` to replace `A' + B'`) should give a wide enough design space for L2 protocols (maybe they wouldn't be the most fee efficient because they couldn't batch, but we'd live with it)
19:57 < t-bast> It feels like having bigger packages will have too much potential negative impact on layer 1
19:57 < glozow> t-bast: i think that's doable
19:58 < harding> glozow: relaying 1+1 as a package seems like it would be powerful, but it would have to allow for the parent already having other children in the mempool (e.g. through standard BIP125 rules).
19:58 < glozow> harding: right
19:59 <@ariard> rgrant: well i did this approach in my PoC a while back but it's super DoSy as you have to cache the package ids...(and didn't figure out a robust mitigation)
19:59 < glozow> many fun whiteboarding sessions to come
20:00 < rgrant> ariard: understood.  it would be cool if we could pull hints from a paid network like LN.
20:00 < glozow> should we talk about replacing witnesses as well? ariard do you think that's appropriate to discuss here?
20:00 < harding> I guess for txid hints in packages, you don't need to use the full txid, you can use something like BIP152 short ids.
20:00 < t-bast> glozow: that's great, I think that almost any L2 protocol can always design two-steps process where the first tx has a feerate of 0 and the second is there to set the fees
20:00 < harding> That would save lots of bandwidth.
20:00 < glozow> harding: oo!
20:01 <@ariard> t-bast: here a new chan type for you :)
20:02 <@ariard> glozow: yes for sure, though iirc 19645 was orthogonal from package-relay discussion at time, though maybe we should consider as one now?
20:02 < glozow> t-bast is t-best
20:02 < glozow> ariard: yeah. i think it's relevant, especially since we're talking about having replacements with packages
20:02 < harding> lol
20:03 < glozow> 19645: https://github.com/bitcoin/bitcoin/pull/19645
20:03 < darosior> michaelfolkson: and where do these services get this estimation from? either a broken mempool estimation or a bitcoind's estimation: https://bitcoin.stackexchange.com/a/96491/101498 . Note also how relying on a centralized fee est service for L2 is a huge SPOF
20:03 <@ariard> t-bast: i believe there is an awful edge-case in our orphan logic which would recommend to do always 1-CSV in chain of transactions with competing interest, here  https://github.com/bitcoin/bitcoin/pull/21148#discussion_r587522262 though need more thinking :/
20:04 < darosior> michaelfolkson: but to answer your question no it does not compute the feerate of an entire block
20:04 <@ariard> glozow: i agree it's relevant, though maybe a reduction of the issue is already having wtxid-replacement at the transaction level?
20:05 < t-bast> ariard: thanks for the link, I'll look into that
20:05 < glozow> ariard: yeah, having it at the single-transaction level is probably the harder part
20:05 < harding> ariard: in 19645, I just quick skimmed the diff and it looks like it's using the regular replacement rules, e.g. higher feerate, higher absolute fee?
20:05 < t-bast> ariard: I think CSV-1 is usually acceptable for L2 protocols
20:05 < harding> ariard: is that correct?
20:06 <@ariard> harding: yes it's not modifying bip125 rule so unless you have `incrementalrelayfee`=0 wtxid-replacement won't work
20:06 <@ariard> like rbf rule 4 requires to increase the absolue fee, but that's locked-in in the same-txid part of any tx?
20:06 < glozow> for witness replacement, i don't think it should go through the normal route. perhaps a similar evaluation of whether it's paying for its bandwidth, but it wouldn't need to rip anything out of mempool. you'd just need to update ancestor/descendant entries
20:07 < michaelfolkson> darosior: Thanks. An unlimited sized mempool would be best for network fee rate monitoring but if you had smaller mempool network fee rate in block(s) might be useful (I think...)
20:07 < harding> ariard: oh, right, I'm dumb.
20:08 <@ariard> glozow: ah that's interesting never considered the approach of conserving the branch of transaction
20:08 <@ariard> yep i like it, more conservative with the bandwidth
20:09 < harding> Yeah, I'd be supportive of that approach as long as it was increasing the feerate by some amount to limit bandwidth wasting.
20:09 < glozow> yeah. witness needs to shrink enough to bump the feerate by at least min relay fee
20:09 < glozow> you'd just go through and change the ancestor/descendant sizes of the entries
20:09 <@ariard> yeah it would move rule 4 from a check on a relay fee in absolue fee to one in feerate? like with a ratio?
20:10 < glozow> mhm, absolute fee wouldn't change, so that rule wouldn't make as much sense for witness replacement
20:10 < glozow> ratio of witness data to nonwitness data?
20:10 < glozow> or old witness data to new witness data?
20:11 <@ariard> glozow: i mean a feerate ratio, though it's really intuitive
20:11 < t-bast> in practice though I'm not sure there is a lot of room to change the witness enough to meaningfully influence the feerate, as what you put in the witness is probably very constrained (in order to correctly satisfy scripts), isn't it?
20:12 < harding> t-bast: taproot.
20:12 <@ariard> like let's say your wtxid-replacement must pay 10% more in feerate than the replaced one, something like this hmmm?
20:12 < t-bast> harding: oh, right, that activated :D
20:12 < t-bast> well not activated but locked in
20:12 < glozow> i think there's also the idea of someone trying to pin your transaction with a very bloated witness?
20:12 < t-bast> good point, I'm not thinking with a taproot mindset yet
20:13 < glozow> so either they're not pinning it very much, or you'll be able to do a significant witness shrink?
20:13 < harding> t-bast: tapscripts can be unlimited in size, so with current rules you could in theory go from a ~100,000 vbyte witness to an empty witness.
20:13 < michaelfolkson> Can someone give me the TL;DR on replacing witnesses? You broadcast a witness and then work out you could have used a cheaper witness?
20:13 <@ariard> t-bast: if you're spending the 30th in depth tapscript gonna be hard to be most fee-efficient than the first one :) ?
20:13 < t-bast> harding: yeah so you need to carefully take this into account when designing your tree
20:14 < harding> michaelfolkson: it's more a case of you have a UTXO shared by two parties (e.g. LN) and Alice's witness for her branch is 1,000 vbytes but Bob's is only 250 vbytes.
20:14 <@ariard> michaelfolkson: yep for example a 1-1 + timelock is shorter than a 4-4 multisig?
20:14 < harding> t-bast: if you're near the limits, yeah, but we obviously can't support many people creating 100,000 vbyte transactions.
20:15 <@ariard> harding: oooh, forget about that so yeah it's kind of a pinning vector as glozow pointed out?
20:15 < t-bast> It's interesting, I didn't realize that this is a very important point to take into account when designing L2 protocols on top of Taproot
20:15 < rgrant> michaelfolkson: an adversary forces CPFP consideration with a large witness, so you need to either create another level of CPFP, or propose a smaller package.
20:15 < harding> t-bast: miniscript should tell you your worst case tx size, so anyone using that should be safe.
20:15 < t-bast> harding: thanks for the explanations!
20:17 < harding> glozow: I don't know how bad the witness pinning risk is because, in a contract protocol, only your counterparties can do that and y'all agreed to the contract up front, so hopefully somebody ran it through miniscript and looked at what the worst case witness size was.
20:17 < michaelfolkson> harding: And in your example you want to use Bob's witness instead of Alice's witness even though Alice's witness was previously broadcast?
20:18 <@ariard> glozow: hmmm we might have a theoritical issue in the future with the in-place replacement approach where a bigger witness is smaller in feerate than the replaced one but override package-limits, like an annex tag
20:18 < harding> For something like LN, the best case is going to be a taproot keypath spend (16 vbyte witness) and the worst case is going to be, what, 150 vbyte witness?  That's not a huge difference, I think, even when fees are very high.
20:18 <@ariard> (super-edgy-case)
20:18 <@ariard> harding: agree it's more defense-in-depth here?
20:19 < glozow> harding: ah, i didn't know you could see worst case witness size :O
20:19 < harding> ariard: yeah, and we do want make it easier for people to get smaller transactions confirmed.  It's good for the contract protocol users and it's good for everyone else too.
20:20 < harding> glozow: miniscript is AMAZING.
20:20 < michaelfolkson> glozow: I didn't know that either
20:20 < darosior> harding: +1, no +2 even
20:20 < michaelfolkson> A distribution of witness sizes (including means, medians etc)? Lol
20:21 <@ariard> wanna chat about package-relay in the context of N-party, like more than 2?
20:22 < glozow> ariard: er what do you mean by annex tag and override package-limits? sorry
20:22 < glozow> ariard: yes sure
20:23 <@ariard> glozow: well the bip341 annex could allow a small witness to have its feerate inflated due to a special marker
20:23 <@ariard> and then you could have a same-txid-different-wtxid coming after with a lower feerate but higher vbytes size, just overflow package limits?
20:23 <@ariard> but not sure it's worthy to mind, it's assuming some soft-fork to define the annex
20:23 < harding> ariard: I don't think that's correct.
20:24 < darosior> Not yet
20:24 < t-bast> ariard: does N party change anything? As long as the N parties collaborate on one tx, N>2 should be the same as N=2, doesn't it?
20:24 < darosior> But it was a proposed idea
20:24 < harding> ariard: first, feerate is purely a policy concept and annex operates at the consensus level.
20:24 <@ariard> harding: ah sorry, which part?
20:24 < harding> ariard: second, an annex can increase the weight of a transaction; it cannot decrease it.
20:24 < darosior> harding: iirc aj suggested it could be a soft fork for giving a meaning to annex
20:25 < darosior> (for context this is because the ratio of sigop per WU was moved to consensus in Taproot and instead of stuffing your witness to pass the limit you could just set the annex to a given value)
20:26 < harding> If you can't decrease the weight of a transaction and a new witness can't change its absolute fee, then I don't believe you can increase the feerate by increasing the size of a transaction.
20:26 < darosior> Sorry i misread what ariard said, i thought it was about *lowering* the feerate.
20:27 < harding> (Obviously, because feerate is a policy concept, you can write economically irrational transaction selection code, but I don't think that's what's being described here.)
20:27 <@ariard> harding: but the replacement witness might not have an annex ? where the replaced said-annex would artificially bump the WU
20:28 <@ariard> though not sure it's worthy to go further, we're talking about something without consensus-meaning for now
20:28 < harding> ariard: hmm, I'll look into that more, but agree we're getting far afield now.
20:29 <@ariard> ah right assuming the artificial-WU-bump is reflected in our mempool policy, we should be good, forget about what i was saying
20:29 < glozow> sooo i've gathered that it would be really beneficial to have replacements enabled, 1 parent + 1 child packages? and we should get cracking on witness replacements.
20:30 < t-bast> glozow: ACK, ship it ;)
20:30 < harding> glozow: SGTM.
20:30 < darosior> glozow: this is what i got too
20:30 < rgrant> does anything prevent my node from proposing package {A B}, and {B C}?
20:30 < rgrant> (as a way to propose {A B C}?
20:31 <@ariard> yep SGTM, though we might have to reconsider RBF rule 3 and the higher-fee requirement
20:31 <@ariard> s/and/on/g
20:31 < t-bast> rgrant: would it be different from proposing {A B} and then simply adding C?
20:31 < glozow> wonderful, thank you! I really really appreciate you all providing this info :D
20:31 < harding> ariard: rule three doesn't require a higher fee, at least as written, it requires an equal or greater fee.
20:32 < t-bast> rgrant: it feels to me that the goal of package relay here is really to get A to propagate
20:32 < harding> ariard: please don't tell my I screwed that up too.  :-(
20:32 < harding> s/my/me/
20:32 <@ariard> harding: well if you combine with rule 4 that's a higher fee requirement ;)
20:33 < rgrant> t-bast: yeah, okay.  it just feels a bit wrong to only solve one level, so intuitively i want to push for more.  but there are other proposal for that.
20:33 <@ariard> assuming the default setting of `incrementalrelayfee` ?
20:33 <@ariard> of 1000 sat per KB iirc
20:33 < t-bast> rgrant: I think that if you got {A B} to propagate as a package, it usually means that if A had been confirmed, B would have propagated on its own, so C wouldn't add anything. But I may be missing some cases though.
20:34 < darosior> ariard: but it's a feerate
20:34 < glozow> rgrant: no, i don't think {A, B} + {B, C} would work if, for example, A and B were zero fee and C was supposed to pay for both
20:34 < t-bast> rgrant: and if A has been evicted, the {B C} package wouldn't propagate because it would be an orphan package
20:34 < rgrant> t-bast: well, if neither A nor B are enough, then you need {A B C}.  but yeah my question wasn't well formed because then {A B} won't happen.
20:34 < t-bast> rgrant: got it
20:34 < glozow> that's not a "perfect" package relay but it would make it a bit harder to implement
20:35 < t-bast> rgrant: I think it shouldn't fundamentally restrict the design space for L2 protocols (but I may be wrong)
20:35 < t-bast> rgrant: what we'd do with a chain of 3 txs, we should be able to split into packages of 2 at a time
20:36 < darosior> ariard: for the absolute fee i'm pretty sure it's >= old_abs_fee
20:36 < t-bast> rgrant: at potentially the cost of a 1-block relative delay somewhere and a bit more fees to pay, but that's an ok trade-off IMHO
20:36 < rgrant> t-bast: once we get into BIP119, then some of the MAST possibilities are not resolved in one transaction, but may ratchet state through several on-chain transactions.
20:36 <@ariard> darosior: yeah i was thinking about nDeltaFees < ::incrementalRelayFee
20:37 < darosior> Gotta run now. Thanks for working on this and participating glozow. And thanks ariard for organizing, i think your efforts moved things forward :) 
20:37 < t-bast> rgrant: OP_CTV is on my rabbit hole list, but I don't have enough context on that one yet!
20:37 < rgrant> darosior: CU
20:38 <@ariard> darosior: thanks for participating
20:38 <@ariard> yeah let's end here
20:38 <@ariard> #endmeeting